While the ACSLS Agent is a relatively simple application, it has multiple dependencies, any of which could prevent the Agent from responding to a snmpget request or to a trap condition.
The running state of the ACSLS Agent is revealed by the service utility on your Solaris or Linux server.
On Solaris, use svcs acsnmp.
If acsnmp fails to start, the SMF daemon places acsnmp in maintenance. To gather clues about why it failed to start, you can consult the tail of the SMF start log, To locate the start log, issue the command, svcs -l acsnmp and look for the logfile definition. Then review the last few lines in that log:
# tail -20 /var/svc/log/application-management-acsnmp:default.log
On Linux, use service acsnmp status.
The service command reveals only whether the Agent is running or is stopped.
AcslsAgtd.logThe AcslsAgtd.log is found in the top-level ACSNMP directory. It tracks start-up and shut-down events and any significant errors encountered during the operation of the ACSLS Agent.
agent CommandThere are multiple configuration and operational dependencies that must be completed and operational before the ACSLS Agent can respond to SNMP requests. There is a command called agent in the $ACSNMP_HOME/utils directory. This command is a helpful troubleshooting aid when attempting to isolate which (if any) of the various system dependencies are missing.
The command, agent status, is useful to view not only the status of the ACSLS Agent, but also to see the status of all dependent services, including the:
Net-SNMP agent daemon (snmpd).
ACSLS application (acsls).
SNMP server side interface to ACSLS (snmpssi).
ACSLS Agent daemon (AcslsAgtd).
Port connection to the Master Agent.
The command, agent status, also checks for a configured V1 user rocommunity established for read-only access to the ACSLS MIB. The rocommunity must be defined in the snmpd.conf file. Community definition is also required in the AcslsAgtd.cfg file, but only if multiple communities are found in snmpd.conf and only one specific community is intended for use by the ACSLS Agent.
Once dependencies are checked and a valid rocommunity is found, the agent status command proceeds to exercise the Agent by submitting a snmpget command, requesting the version of the ACSLS Agent. A successful result from this test reveals the Agent software version.
The agent status command also looks for configured trap destinations.It tests for network access to each defined trap host and displays the result. If a listener is configured and running on the localhost, the connection to the trap port is tested and the result displayed.
Finally, the agent status command issues snmpget to obtain the most recent trap message broadcast by the ACSLS Agent
The agent utility may also be used as an alternate start-up command. Using agent start to start the ACSLS Agent, you are able to watch the progress of the utility as it comes up. If any dependencies are lacking, they are displayed during the start-up sequence. This agent start command cannot be used while acsnmp is online to Solaris SMF or to the Linux service utility.
Having verified the Agent, you can use snmp commands directly. Use translate -n to capture any specific OIDs of interest, then submit an snmpget command for that OID. For example, if the rocommunity is acs_user, reveal the version string for the Agent software, by running snmpget with the corresponding numeric IOD:
# snmpget -v1 -c acs_user localhost 1.3.6.1.4.1.1211.1.11.1.1.0