System Management Guide: Communications and Networks

Troubleshooting the SNMP Daemon

If the snmpd agent is not behaving as expected, the following are some hints to help determine and correct the problem. It is strongly recommended that you start up the snmpd agent with some type of logging. If invoking the snmpd daemon causes problems, it is strongly recommended that the syslogd daemon be set up for logging at the daemon facility and DEBUG severity level. See 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 will 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 the snmpd command was invoked without the System Resource Controller (SRC), the required usage statement is echoed to the screen. If the snmpd daemon was invoked under SRC control, the usage message is not echoed to the screen. 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.
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 verifies the ownership of the configuration file. If the file is not owned by the root user, the snmpd agent terminates with 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 the -c flag is not specified in the configuration file on the snmpd command line, the /etc/snmpd.conf file does not exist. If the /etc/snmpd.conf file is accidentally removed, reinstall the bos.net.tcp.client image or else reconstruct the file with the appropriate configuration entries as defined in the snmpd.conf file management page. If the configuration file is specified with the -c flag on the snmpd command line, make sure that the file exists and that the file is owned by the root user. The full path and file name of the configuration file must be specified or else the default /etc/snmpd.conf file will be used.
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 is 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 the complete path and file name of the configuration file is specified when the snmpd daemon is invoked. The snmpd daemon forks and changes to the root directory at invocation. If the complete path name of the configuration file is not specified, 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. Verify the lo0, loopback, device is up. If the device is down, an * (asterisk) displays 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
```
Verify that the snmpd daemon has a route to the host where the requests are issued.
Solution: On the host where the snmpd daemon is running, add a route to the host where the route add command is issued. See the route command for more information.
Check to see that the host name 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 a view entry for the specified view name is specified in the community entry in the configuration file. If there is a specified view name in the community entry, but there is no corresponding view entry, the snmpd agent does 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 iso is specified as the MIB subtree for the view entry, verify that iso.3 is specified. 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. Verify that the host issuing the SNMP request is included in the community being specified 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 that is 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. For general access to this community name, the network mask must be 0.0.0.0. If the network mask is specified to be 255.255.255.255, the snmpd agent is configured 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 the request again.
Make sure the access mode in the community entry corresponds with the request type. When 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, a noSuchName error message is returned, the following might be the reason:

The set request 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.