Hi Dave, Ashwin and All, After checking from another system, I was able to communicate with SNMP but upon rebooting, the daemon didn't auto start. I copied the file from dist/snmpd-init.d to /etc/init.d/snmpd, set the permissions to executable and updated the 'daemon' code to 'start-stop-daemon' as required in debian; this unfortunately still didn't work.
So, I went back to the beginning, uninstalled my compiled version of net SNMP, used APT-get and installed that copy of netsnmp. (apt-get install snmpd). This installed as expected and auto-started, so I copied the init file for this one and uninstalled it again. I then re-compiled v5.6.1 of net snmp again and followed Ashwin's instructions again to the letter. Still no auto starting, so I copied the file which I got from APT into init.d and it's now auto starting. Great; but puzzled as to why it didn't do it right the first time. Side note: Couldn't the 'make install' be configured to do all this additional setup and shouldn't it add the daemon auto-start in /etc/init.d? The thing that is quite strange to me is something which I asked in the forum some time ago, but didn't really get a helpful answer. When using my compiled version of Net SNMP, queries for the bandwidth on an interface gives me a data value every 3 seconds, any quicker and NetSNMP gives me a 0 (zero) value. When I tested this with the APT version of NetSNMP, the data value was only every 15 seconds, then when I re-compiled again back to the latest version, it was again every 3 seconds. This leads me to believe this is some type of configuration value. I'd like to be able to get per-second values from the interfaces, do you know the command I can use to change from the 3-second values to a per-second value? Thanks again for your help. Steve. On 16/02/2011 9:01 PM, Dave Shield wrote: > On 16 February 2011 09:31, Steve (Telsat Pacific)<st...@telsat.vu> wrote: > > >> ... this was the only output I got from [the agent]: >> wcs001:~# snmpd -f -Le >> Turning on AgentX master support. >> NET-SNMP version 5.6.1 >> ^CReceived TERM or STOP signal... shutting down... >> wcs001:~# > OK - so it's not complaining about anything. > That's a good start. > > So there are two possible reasons why you're not > getting a response to your query: > - either the agent isn't receiving the request, or > - the agent gets the request, but refuses to process it. > > To determine which, try running the agent using > > snmpd -f -Le -d > > and then query it again. > You should see dumps of the incoming (?and outgoing) > request packets. Do you see this or not? > > If not, then I'd suspect access control problems. > What is the exact command you are using to test with? > > If you do see incoming packets (but nothing outgoing), > then that's almost certainly access control. > What is the exact command you are using to test with? > What are the contents of the snmpd.conf file? > > (If you see both incoming and outgoing packets, that's > a more unusual situation. But we'll cross that bridge > when we come to it!) > > > >> It seems as if somehow, someway, the installation's been messed up. > Not necessarily. > We can't really say that until we've tracked down what is actually wrong. > > >> I would have thought the setup of the snmp service would have been >> done by the 'make install'. > Unfortunately, things aren't quite that simple. > The Net-SNMP suite is designed to run on a range of different operating > systems, all of which have different mechanisms for starting services. > Even within the Linux world, the /etc/init.d mechanism is not necessarily > consistent across all distributions - let alone when you include Solaris, > HP-UX, etc (not to mention Windows with Cygwin and/or MinGW) > > (And looking more closely, the dist/snmpd-init.d script seems to be > designed for Solaris, so may not work directly on Linux systems!) > > Trying to handle all of this automatically within the "make install" > system is non-trivial. Particularly since this could be installed in > parallel to a vendor-supplied version. We cannot simply over-write > the files from an RPM- or deb- package > The only "safe" approach is to install the basic software, and let > the network or system administrator take care of integration issues. > > > Dave > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
