snmpd strangeness
I just noticed something odd and am looking for ideas... As you can see from the top snippet below, snmpd is getting hammered by something. As a comparison, the load averages for this quad-core box are usually close to zero. I'm not even sure I'm using snmpd for anything... not even sure what it is, precisely. I'm digging into docs at the moment, but any ideas much appreciated. -- John last pid: 38974; load averages: 1.24, 1.40, 1.58 342 processes: 6 running, 336 sleeping CPU states: 13.7% user, 0.0% nice, 13.9% system, 0.3% interrupt, 72.1% idle Mem: 5997M Active, 596M Inact, 420M Wired, 206M Cache, 214M Buf, 457M Free Swap: 16G Total, 123M Used, 16G Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 45136 root1 1040 2636M 2621M CPU5 4 254.1H 103.91% snmpd 37368 www 1 200 193M 46232K lockf 6 0:05 3.91% httpd 38819 identry 1 -320 7688K 2648K CPU0 0 0:02 1.61% top ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wed, Nov 19, 2008 at 10:57:50AM -0500, John Almberg wrote:
I just noticed something odd and am looking for ideas...
As you can see from the top snippet below, snmpd is getting hammered by
something. As a comparison, the load averages for this quad-core box are
usually close to zero.
I'm not even sure I'm using snmpd for anything... not even sure what it
is, precisely.
I'm digging into docs at the moment, but any ideas much appreciated.
I'm greatly concerned by the fact that you have a process on your
machine taking up 103% CPU time (possible on a quad-core machine),
taking up 2621MBytes of memory (RSS), yet you have no idea what it is,
what SNMP is, or why said process is running on your machine. :-)
You can truss the pid to find out what it's doing, but based on the
above I'm not sure the truss output will be of much use to you.
I would recommend finding out who/what started it by looking at the ppid
of the process (ps -alx | grep 45136, then look at the 3rd column which
is the ppid; then do ps -alx | grep {ppid}). It's very possible the
ppid will be 1, which is init, which means in this case it was probably
started by a script in /usr/local/etc/rc.d.
I would then recommend using gcore on the snmpd pid, which will write
out a very large file (~2.6GB) to $PWD. You can then examine that
later.
I would then recommend killing it off, then go on a quest to find out
why net-snmpd is on your machine -- and equally as odd, why it's
running. For this to start, something has to be in /etc/rc.conf to
initialise it.
There's also the possibility that the process running isn't snmpd at
all, but rather a binary of a hacker who has gained access to your box,
especially given that you have no idea what it is.
last pid: 38974; load averages: 1.24, 1.40, 1.58
342 processes: 6 running, 336 sleeping
CPU states: 13.7% user, 0.0% nice, 13.9% system, 0.3% interrupt, 72.1%
idle
Mem: 5997M Active, 596M Inact, 420M Wired, 206M Cache, 214M Buf, 457M
Free
Swap: 16G Total, 123M Used, 16G Free
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
45136 root1 1040 2636M 2621M CPU5 4 254.1H 103.91% snmpd
37368 www 1 200 193M 46232K lockf 6 0:05 3.91% httpd
38819 identry 1 -320 7688K 2648K CPU0 0 0:02 1.61% top
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Nov 19, 2008, at 11:49 AM, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 10:57:50AM -0500, John Almberg wrote: I just noticed something odd and am looking for ideas... As you can see from the top snippet below, snmpd is getting hammered by something. As a comparison, the load averages for this quad-core box are usually close to zero. I'm not even sure I'm using snmpd for anything... not even sure what it is, precisely. I'm digging into docs at the moment, but any ideas much appreciated. I'm greatly concerned by the fact that you have a process on your machine taking up 103% CPU time (possible on a quad-core machine), taking up 2621MBytes of memory (RSS), yet you have no idea what it is, what SNMP is, or why said process is running on your machine. :-) That's an easy one to answer... Someone else installed FreeBSD on this machine. I have figured out MOST of what is on this box, but I'm occasionally surprised, like in this case. However, now that I've read through the installer's notes, I see that he had exotic plans for snmp monitoring. From what I can tell, he never got it working properly. In the meantime, I killed off the process. I had to take a sledgehammer to it, since a normal stop didn't work: [EMAIL PROTECTED]:log] sudo /usr/local/etc/rc.d/snmpd stop Stopping snmpd. Waiting for PIDS: 45136t, 45136op, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136^C [EMAIL PROTECTED]:log] sudo kill -SIGKILL 45136 This makes me wonder if the process was just hung in some bad way, eating up cpu cycles? Out of curiosity, I then restarted it. It seemed to run without problem after the restart, but after watching it for awhile, I stopped it again. I don't think it's doing anything useful at the moment. Now I'm curious about snmp, so perhaps I'll try to figure out how to get it to something useful. This machine has 8 hard drives, and is located in Manhattan, so I would certainly like to be informed if one of the raid drives went on the blink. That was one of the things he was trying to get working. Thanks: John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
taking up 2621MBytes of memory (RSS), BTW, after restarting, the process was a much more reasonable size. Another indicator that something had gone seriously wrong with it. 41659 root1 960 23072K 6636K select 0 0:05 0.34% snmpd Luckily, Monit alerted me to the problem before it got completely out of hand. Love that program. -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wed, Nov 19, 2008 at 12:11:36PM -0500, John Almberg wrote: On Nov 19, 2008, at 11:49 AM, Jeremy Chadwick wrote: On Wed, Nov 19, 2008 at 10:57:50AM -0500, John Almberg wrote: I just noticed something odd and am looking for ideas... As you can see from the top snippet below, snmpd is getting hammered by something. As a comparison, the load averages for this quad-core box are usually close to zero. I'm not even sure I'm using snmpd for anything... not even sure what it is, precisely. I'm digging into docs at the moment, but any ideas much appreciated. I'm greatly concerned by the fact that you have a process on your machine taking up 103% CPU time (possible on a quad-core machine), taking up 2621MBytes of memory (RSS), yet you have no idea what it is, what SNMP is, or why said process is running on your machine. :-) That's an easy one to answer... Someone else installed FreeBSD on this machine. I have figured out MOST of what is on this box, but I'm occasionally surprised, like in this case. However, now that I've read through the installer's notes, I see that he had exotic plans for snmp monitoring. From what I can tell, he never got it working properly. Interesting. For small installations, e.g. super simple monitoring, most people prefer to use bsnmpd(1), which comes with FreeBSD. The docs are a bit sparse though, and the config syntax is weird + touchy. I've tinkered a bit with it though. In the meantime, I killed off the process. I had to take a sledgehammer to it, since a normal stop didn't work: [EMAIL PROTECTED]:log] sudo /usr/local/etc/rc.d/snmpd stop Stopping snmpd. Waiting for PIDS: 45136t, 45136op, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136, 45136^C [EMAIL PROTECTED]:log] sudo kill -SIGKILL 45136 This makes me wonder if the process was just hung in some bad way, eating up cpu cycles? Looks like it was wedged on a single CPU maybe? (If it was spiralling out of control thread-wise, I'd expect to see it chewing up ~400% CPU, e.g. 100% per core). More interesting is the fact that it was taking up 2.6GB of RAM. That reeks of a memory leak somewhere. Maybe the snmpd.conf tried to tie in some shell scripts or executables? I've seen this behaviour at work on Solaris, but it's rare. (More common, we see kernel panics when using old versions of Net-SNMP -- yeah, you read that right, kernel panics. Seems the Solaris kernel has some SNMP support in it -- yes, the kernel!) You would have to work with the Net-SNMP folks to figure out what the cause was. Out of curiosity, I then restarted it. It seemed to run without problem after the restart, but after watching it for awhile, I stopped it again. I don't think it's doing anything useful at the moment. Then keep it off. It opens up a listening port, amongst other things. If you're not using it, don't run it. :-) Now I'm curious about snmp, so perhaps I'll try to figure out how to get it to something useful. This machine has 8 hard drives, and is located in Manhattan, so I would certainly like to be informed if one of the raid drives went on the blink. That was one of the things he was trying to get working. Net-SNMP won't give you the status of the RAID. Neither will bsnmpd(10. FreeBSD simply does not have the hooks to make this possible. Someone needs to write the code. I do not recommend relying on shell scripts tied into Net-SNMP to accomplish this either (for a lot of very good reasons); write the code in native C. It also greatly depends on what you're using for RAID. If a hardware controller, good luck getting the status out of an API natively (sans Areca, which I believe offers an API) -- you'll resort to shell scripts and CLI binaries, in which case you're *easily* better off with a cronjob, periodic(8), or a log monitor daemon. It never ceases to amaze me how people to try shove crazy stuff into SNMP stacks which should be done elsewhere. :-) Even Juniper's JunOS, which provides an extensive SNMP extension, does not provide everything desired. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
Now I'm curious about snmp, so perhaps I'll try to figure out how to get it to something useful. This machine has 8 hard drives, and is located in Manhattan, so I would certainly like to be informed if one of the raid drives went on the blink. That was one of the things he was trying to get working. Net-SNMP won't give you the status of the RAID. Neither will bsnmpd (10. FreeBSD simply does not have the hooks to make this possible. Someone needs to write the code. I do not recommend relying on shell scripts tied into Net-SNMP to accomplish this either (for a lot of very good reasons); write the code in native C. It also greatly depends on what you're using for RAID. If a hardware controller, good luck getting the status out of an API natively (sans Areca, which I believe offers an API) -- you'll resort to shell scripts and CLI binaries, in which case you're *easily* better off with a cronjob, periodic(8), or a log monitor daemon. This machine has an Intel motherboard and a hardware raid controller. From what I can tell, there is some Intel software installed on the machine that makes hardware faults visible to snmp. That last sentence makes it sound like I know more than I do about this situation. I'm just reading from notes. :-) And I have an Intel disk that came with the motherboard that hints at the same type of thing. I've just scanned the docs on the disk... looks extraordinarily complicated. I think I'll leave this to a rainy day when I have nothing to do (ha!) -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wed, Nov 19, 2008 at 12:34:55PM -0500, John Almberg wrote: Now I'm curious about snmp, so perhaps I'll try to figure out how to get it to something useful. This machine has 8 hard drives, and is located in Manhattan, so I would certainly like to be informed if one of the raid drives went on the blink. That was one of the things he was trying to get working. Net-SNMP won't give you the status of the RAID. Neither will bsnmpd (10. FreeBSD simply does not have the hooks to make this possible. Someone needs to write the code. I do not recommend relying on shell scripts tied into Net-SNMP to accomplish this either (for a lot of very good reasons); write the code in native C. It also greatly depends on what you're using for RAID. If a hardware controller, good luck getting the status out of an API natively (sans Areca, which I believe offers an API) -- you'll resort to shell scripts and CLI binaries, in which case you're *easily* better off with a cronjob, periodic(8), or a log monitor daemon. This machine has an Intel motherboard and a hardware raid controller. From what I can tell, there is some Intel software installed on the machine that makes hardware faults visible to snmp. That would require Net-SNMP to be linked to that software (or library) directly. Two things can't just magically talk to one another. :-) AFAIK, Intel does not provide such software on FreeBSD, but I could be complete wrong here. They primarily focus on Linux, like most companies do. That last sentence makes it sound like I know more than I do about this situation. I'm just reading from notes. :-) And I have an Intel disk that came with the motherboard that hints at the same type of thing. I've just scanned the docs on the disk... looks extraordinarily complicated. I don't know what controller it is, but Net-SNMP doesn't have any sort of out-of-the-box support for any kind of RAID card. See above for what's needed. I just hope the card is an actual RAID card and not BIOS-level RAID like Intel MatrixRAID. If it is MatrixRAID, I highly recommend you back the entire machine up and reinstall without MatrixRAID, otherwise when you lose a disk or need to rebuild your array, you'll find your array broken/gone, be completely unable to rebuild it, or kernel panics. Note that all of this stuff works just fine on Linux; the issues listed are with FreeBSD. Generally speaking, we (the open-source world) have gotten to the point with OS-based software RAID (e.g. Linux LVM, FreeBSD ccd/gvinum/ZFS, OpenSolaris ZFS) where it offers significant advantages over hardware RAID. There are good reasons to use hardware RAID, but in those scenarios admins should be looking at buying an actual filer, e.g. Network Appliance. Otherwise, for simple systems (even stuff like 2U or 3U boxes with many disks, e.g. a low-cost filer), stick with some form of OS-based software RAID if possible. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
This machine has an Intel motherboard and a hardware raid controller. From what I can tell, there is some Intel software installed on the machine that makes hardware faults visible to snmp. That would require Net-SNMP to be linked to that software (or library) directly. Two things can't just magically talk to one another. :-) As I said, I really have no idea. Now that I'm reading more deeply in the notes... the monitoring was supposed to be with IPMI. No idea what that is, either, but I thought I'd toss it into the mix. AFAIK, Intel does not provide such software on FreeBSD, but I could be complete wrong here. They primarily focus on Linux, like most companies do. That last sentence makes it sound like I know more than I do about this situation. I'm just reading from notes. :-) And I have an Intel disk that came with the motherboard that hints at the same type of thing. I've just scanned the docs on the disk... looks extraordinarily complicated. I don't know what controller it is, but Net-SNMP doesn't have any sort of out-of-the-box support for any kind of RAID card. See above for what's needed. I just hope the card is an actual RAID card and not BIOS-level RAID like Intel MatrixRAID. If it is MatrixRAID, I highly recommend you back the entire machine up and reinstall without MatrixRAID, otherwise when you lose a disk or need to rebuild your array, you'll find your array broken/gone, be completely unable to rebuild it, or kernel panics. Note that all of this stuff works just fine on Linux; the issues listed are with FreeBSD. Generally speaking, we (the open-source world) have gotten to the point with OS-based software RAID (e.g. Linux LVM, FreeBSD ccd/gvinum/ZFS, OpenSolaris ZFS) where it offers significant advantages over hardware RAID. There are good reasons to use hardware RAID, but in those scenarios admins should be looking at buying an actual filer, e.g. Network Appliance. Otherwise, for simple systems (even stuff like 2U or 3U boxes with many disks, e.g. a low-cost filer), stick with some form of OS-based software RAID if possible. That's good to know. I was told just the opposite by the guy selling the $650 RAID cards. Who'd have thunk? The card in the box is a Intel 18E PCI-Express x8 SAS/SATA2 Hardware ROMB RAID with 128MB Memory Module and 72 Hour Battery Backup Cache $625 as shown on the packing list, so I hope it's a good one. -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wednesday 19 November 2008 20:37:05 John Almberg wrote: This machine has an Intel motherboard and a hardware raid controller. From what I can tell, there is some Intel software installed on the machine that makes hardware faults visible to snmp. That would require Net-SNMP to be linked to that software (or library) directly. Two things can't just magically talk to one another. :-) As I said, I really have no idea. Now that I'm reading more deeply in the notes... the monitoring was supposed to be with IPMI. No idea what that is, either, but I thought I'd toss it into the mix. http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wed, Nov 19, 2008 at 02:37:05PM -0500, John Almberg wrote: This machine has an Intel motherboard and a hardware raid controller. From what I can tell, there is some Intel software installed on the machine that makes hardware faults visible to snmp. That would require Net-SNMP to be linked to that software (or library) directly. Two things can't just magically talk to one another. :-) As I said, I really have no idea. Now that I'm reading more deeply in the notes... the monitoring was supposed to be with IPMI. No idea what that is, either, but I thought I'd toss it into the mix. Ah, IPMI... it's another one of those technologies which is a great idea, but often horribly implemented. The most common use is for remote management (serial-over-IP, or even KVM-over-IP), access to hardware sensors (fans, temps, voltages), and for some other monitoring-related things. It's very useful -- when it works. :-) On Intel boards (native Intel IPMI) it might be great. There's been a lot of problem reports with Supermicro's IPMI, and most are IPMI card firmware bugs. I just hope the card is an actual RAID card and not BIOS-level RAID like Intel MatrixRAID. If it is MatrixRAID, I highly recommend you back the entire machine up and reinstall without MatrixRAID, otherwise when you lose a disk or need to rebuild your array, you'll find your array broken/gone, be completely unable to rebuild it, or kernel panics. Note that all of this stuff works just fine on Linux; the issues listed are with FreeBSD. Generally speaking, we (the open-source world) have gotten to the point with OS-based software RAID (e.g. Linux LVM, FreeBSD ccd/gvinum/ZFS, OpenSolaris ZFS) where it offers significant advantages over hardware RAID. There are good reasons to use hardware RAID, but in those scenarios admins should be looking at buying an actual filer, e.g. Network Appliance. Otherwise, for simple systems (even stuff like 2U or 3U boxes with many disks, e.g. a low-cost filer), stick with some form of OS-based software RAID if possible. That's good to know. I was told just the opposite by the guy selling the $650 RAID cards. Who'd have thunk? Well, hardware RAID has a specific purpose. I like them for the fact that they add a layer of abstraction in front of the OS; that is to say, some of them are bootable even with RAID-5. FreeBSD's bootloader has a lot of difficulty booting off of different things, so adding a layer of abstraction in front is useful. For example, take into consideration that you can't get kernel panic dumps (to disk) using gmirror without a bunch of rigmarole. I forget which GEOM method it is, but one of them you can't boot off of easily. gvinum? geli? I can't remember. There's one or two that the bootstraps don't work with. Hardware RAID can help solve that. The card in the box is a Intel 18E PCI-Express x8 SAS/SATA2 Hardware ROMB RAID with 128MB Memory Module and 72 Hour Battery Backup Cache $625 as shown on the packing list, so I hope it's a good one. Ah, I think it's hardware RAID, and PCIe to boot. Yes, I would recommend keeping that! What does it show up as under FreeBSD? I'm curious what driver it uses, and what your disks show up as (daX or adX; probably daX). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
The card in the box is a Intel 18E PCI-Express x8 SAS/SATA2 Hardware ROMB RAID with 128MB Memory Module and 72 Hour Battery Backup Cache $625 as shown on the packing list, so I hope it's a good one. Ah, I think it's hardware RAID, and PCIe to boot. Yes, I would recommend keeping that! What does it show up as under FreeBSD? I'm curious what driver it uses, and what your disks show up as (daX or adX; probably daX). H'mmm... You are revealing great gaps in my knowledge today, Jeremy. Not that that's hard to do... I've been looking in dmesg.boot and fstab for clues... Not sure if that is where I should be looking, but I figured there would be mount messages in dmsg.boot. Unfortunately, there is a whole bunch of stuff in there I have no clue about. Fascinating reading, though! Does mf0/mf1 sound correct? If not, how would I find the driver info? Typical line in fstab: /dev/mfid0s1a / ufs rw 1 1 -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Wed, Nov 19, 2008 at 03:47:05PM -0500, John Almberg wrote: The card in the box is a Intel 18E PCI-Express x8 SAS/SATA2 Hardware ROMB RAID with 128MB Memory Module and 72 Hour Battery Backup Cache $625 as shown on the packing list, so I hope it's a good one. Ah, I think it's hardware RAID, and PCIe to boot. Yes, I would recommend keeping that! What does it show up as under FreeBSD? I'm curious what driver it uses, and what your disks show up as (daX or adX; probably daX). H'mmm... You are revealing great gaps in my knowledge today, Jeremy. Not that that's hard to do... I've been looking in dmesg.boot and fstab for clues... Not sure if that is where I should be looking, but I figured there would be mount messages in dmsg.boot. Unfortunately, there is a whole bunch of stuff in there I have no clue about. Fascinating reading, though! Does mf0/mf1 sound correct? If not, how would I find the driver info? Typical line in fstab: /dev/mfid0s1a / ufs rw 1 1 That's mfi(4), which is kinda its own thing (neither daX nor adX). Still perfectly usable/decent, and Scott Long (as I call him, famous SCSI guy ;-) ) wrote the driver, so support for it should be available. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
John Almberg wrote: If not, how would I find the driver info? Typical line in fstab: /dev/mfid0s1a / ufs rw 1 1 Hey! # mount to see what is mounted # sysctl dev.mfi to see mfi information I am using mfi in one of my systems. Mfi is LSI MegaSAS. Very good and fast raid controller, but unfortunatelly without management software for BSD. :) O.K. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snmpd strangeness
On Nov 19, 2008, at 4:09 PM, Ott Köstner wrote: John Almberg wrote: If not, how would I find the driver info? Typical line in fstab: /dev/mfid0s1a / ufs rw 1 1 Hey! # mount to see what is mounted I did this, but /dev/mfid0s1a didn't make much sense to me. # sysctl dev.mfi to see mfi information This I didn't know about. Thanks! I am using mfi in one of my systems. Mfi is LSI MegaSAS. Very good and fast raid controller, but unfortunatelly without management software for BSD. Thanks for the additional info! Brgds: John___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
