[ Previous | Next | Table of Contents | Index | Library Home |
Legal |
Search ]
System Management Guide: Communications and Networks
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 SNMP Daemon Logging
Facility , the snmpd command, and the snmpd.conf file for 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 to udp port
161.
Solution: Either
kill the existing snmpd agent or do not try to start up another
snmpd daemon process.
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.
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).
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.
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.
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.
[ Previous | Next | Table of Contents | Index |
Library Home |
Legal |
Search ]