SNMP daemon troubleshooting
Troubleshooting tips for the SNMP daemon include solving termination problems, MIB variable access problems, MIB variable access in community entry problems, noSuchName problems, no response from agent problems, and daemon failures.
Daemon termination problem
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 in Commands Reference, Volume 5 and the snmpd.conf file in Files Referencefor more information on snmpd logging.
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 toudp 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 in Commands Reference, Volume 4for more information.
- Check to see that the host name and the host IP address are the
same value.
Solution: Reset the host name 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 thatiso.3
is specified. The instance of3
is required for the snmpd agent to access theorg
portion of theiso
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.