Problem Determination for the SNMP Daemon

System Management Guide: Communications and Networks

Problem Determination for the SNMP Daemon

If the snmpd agent is not behaving as you expected, following are some hints to help you determine and correct the problem. If you are having problems, it is strongly recommended that you start up the snmpd agent with some type of logging. If you are having trouble with the invocation of the snmpd daemon, it is strongly recommended that you set up the syslogd daemon for logging at the daemon facility and DEBUG severity level. See "SNMP Daemon Logging Facility" , the snmpd command, and the snmpd.conf file for more information on snmpd logging.

Daemon Termination Problem

If the snmpd daemon terminates as soon as it is invoked, the following are possible reasons for failure and probable solutions:

The reason the snmpd daemon terminated should be logged in the snmpd log file or the configured syslogd log file. Check the log file to see the FATAL error message.
Solution: Correct the problem and restart the snmpd daemon.
The snmpd command line usage was incorrect. If you invoked the snmpd command without the System Resource Controller (SRC), the required usage statement should be echoed to the screen. If you invoked the snmpd daemon under SRC control, the usage message will not be echoed to the screen. You will need to check the log file to see the usage message.
Solution: Invoke the snmpd command with the correct usage statement.
The snmpd daemon must be invoked by the root user. The snmpd agent will not run if it is not invoked by the root user.
Solution: Switch to the root user and restart the snmpd daemon.
The snmpd.conf file must be owned by the root user. The snmpd agent checks the ownership of the configuration file. If the file is not owned by the root user, the snmpd agent terminates as this is considered a fatal error.
Solution: Make sure you are the root user, change the ownership of the configuration file to the root user, and restart the snmpd daemon.
The snmpd.conf file must exist. If you did not specify the configuration file on the snmpd command line with the -c flag, the /etc/snmpd.conf file must exist. If you have accidentally removed the /etc/snmpd.conf file, reinstall the bos.net.tcp.client image or else reconstruct the file with the appropriate configuration entries as defined in the snmpd.conf file man page. If you did indeed specify the configuration file on the snmpd command line with the -c flag, make sure that the file exists and that the file is owned by the root user. You must specify the full path and file name of the configuration file if you do not wish to use the default /etc/snmpd.conf file.
Solution: Make sure the specified configuration file exists and that this file is owned by the root user. Restart the snmpd daemon.
The udp port 161 is already bound. Make sure that the snmpd daemon is not already running. Issue the ps -eaf | grep snmpd command to determine if an snmpd daemon process is already executing. Only one snmpd agent can bind to udp port 161.
Solution: Either kill the existing snmpd agent or do not try to start up another snmpd daemon process.

Daemon Failure Problem

If the snmpd daemon fails when you issue a refresh or a kill -1 signal, the following are possible reasons for failure and probable solutions:

The reason the snmpd daemon terminated should be logged in the snmpd log file or the configured syslogd log file. Check the log file to see the FATAL error message.
Solution: Correct the problem and restart the snmpd daemon.
Make sure that you specified the complete path and file name of the configuration file when you invoked the snmpd daemon. The snmpd daemon forks and changes to the root directory at invocation. If you did not specify the complete path name of the configuration file, the snmpd agent cannot find the file on a refresh. This is a fatal error and will cause the snmpd agent to terminate.
Solution: Specify the complete path and file name of the snmpd configuration file. Make sure the configuration file is owned by the root user. Restart the snmpd daemon.
Make sure that the snmpd configuration file still exists. The file may have been accidentally removed after the snmpd agent was invoked. If the snmpd agent cannot open the configuration file, the snmpd agent terminates.
Solution: Recreate the snmpd configuration file, make sure the configuration file is owned by the root user, and restart the snmpd daemon.

MIB Variable Access Problem

If Management Information Base (MIB) variables cannot be accessed from the snmpd agent; if the snmpd agent is running, but the Simple Network Management Protocol (SNMP) manager application times out waiting for a response from the snmpd agent, try the following:

Check the network configuration of the host on which the snmpd agent is running using the netstat -in command. Make sure the lo0, loopback, device is up. If the device is down, there will be an * (asterisk) to the left of the lo0. The lo0 must be up for the snmpd agent to service requests.
Solution: Issue the following command to start up the loopback interface:
```
ifconfig lo0 inet up
```
Make sure that the snmpd daemon has a route to the host where you issued the requests.
Solution: On the host where the snmpd daemon is running, add a route to the host where the SNMP request issued the route add command. See the route command for more information.
Check to see that the hostname and the host IP address are the same value.
Solution: Reset the hostname to correspond to the host IP address.
Check to see that localhost is defined to be the lo0 IP address.
Solution: Define localhost to be the same address used by the lo0 IP address (usually 127.0.0.1).

MIB Variable Access in Community Entry Problem

If a community entry is specified in the configuration file with a MIB view name, but MIB variables cannot be accessed, check the following:

Make sure that you have correctly specified the community entry. If you have specified a view name in the community entry, all fields in the community are absolutely required.
Solution: Specify all fields in the community entry in the configuration file. Refresh the snmpd agent and try your request again.
Make sure the access mode in the community entry corresponds with your request type. If you are issuing a get or get-next request, make sure that the community has read-only or read-write permission. If you are issuing a set request, make sure that the community has read-write permission.
Solution: Specify the correct access mode in the community entry. Refresh the snmpd agent and try your request again.
Make sure that you have specified a view entry for the specified view name in the community entry in the configuration file. If you have indeed specified a view name in the community entry, but you have no corresponding view entry, the snmpd agent will not allow access for that community. A view entry is absolutely required for a view name specified in a community entry in the configuration file.
Solution: Specify a view entry for the view name specified in the community entry. Refresh the snmpd agent and try your request again.
If you have specified iso as the MIB subtree for your view entry, make sure that you have specified iso.3. The instance of 3 is required for the snmpd agent to access the org portion of the iso tree.
Solution: Specify the MIB subtree as iso.3 in the view entry. Refresh the snmpd agent and try your request again.
Check the IP address and network mask in the community entry. Make sure that the host from which you are issuing the SNMP request is included in the community you are specifying with the community name.
Solution: Change the IP address and network mask fields in the community entry in the configuration file to include the host from which you are issuing the SNMP request.

No Response from Agent Problem

If the IP address in the community is specified as 0.0.0.0, but there is no response from the snmpd agent, try the following:

Check the network mask field in the community entry. If you want general access for this community name, the network mask must be 0.0.0.0. If you have specified the network mask to be 255.255.255.255, you have configured the snmpd agent to not allow any requests with the specified community name.
Solution: Specify the network mask in the community entry to 0.0.0.0. Refresh the snmpd agent and try your request again.
Make sure the access mode in the community entry corresponds with your request type. If you are issuing a get or get-next request, make sure that the community has read-only or read-write permission. If you are issuing a set request, make sure that the community has read-write permission.
Solution: specify the correct access mode in the community entry. Refresh the snmpd agent and try your request again.

noSuchName Problem

If in attempting to set an MIB variable that the snmpd agent is supposed to support, noSuchName error message is returned, the following may be the reason:

The set request you issued did not include a community name for a valid community with write access. The SNMP protocol dictates that a set request with a community with inappropriate access privileges be answered with the noSuchName error message.

Solution: Issue the set request with a community name for a community that has write privileges and includes the host from which the set request is issued.