|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
| News | Recommended Links | TEC troubleshooting | TEC Documentation | TEC Rules Programming |
| Tivoli Logfile adapter format filet | TEC Rules Programming | postmsg adapter | Humor | Etc |
Perform the following steps to troubleshoot the UNIX logfile adapter:
- Stop any UNIX logfile adapters that are currently running:
init.tecad_logfile stop- Start the adapter in debug mode.
init.tecad_logfile -d start- Generate some messages to determine if the adapter receives them. You can send e-mail, perform an su, or perform any action that results in a write to syslog. Alternatively, you can use the logger program to generate messages:
logger -t oserv -i execve failed: path: errno 13This generates an Oserv_Exec_Failed event. The message written by logger should match one of the format specifications in the tecad_logfile.fmt file.
- When events arrive, the adapter prints messages to the screen indicating the class and the attribute values in the class.
matched CREATED_PROFILE_MANAGER name is 'Profile1''If you do not see any messages, the adapter is not receiving events from the log file.
Verify that the syslogd daemon is running and is writing any new messages to the system log files in /var/adm or its equivalent, or to the system console, depending on how syslog.conf has been configured to write out messages. For testing purposes, you can temporarily add the following line to syslog.conf:
*.info <Tab> <filename>This enables all messages to be written to a file so you can see what messages have arrived. This file grows large quickly, so make this a temporary change only. You need to refresh the syslogd daemon each time you change syslog.conf to put these changes into effect.- If you see the messages, the adapter is receiving events and processing them. Run the wtdumprl command on the event server and verify that the messages are actually showing up in the reception log. If not, the events were not received by event server or there is a problem with the event server reception process. Check the adapter configuration file to verify that ServerLocation and ServerPort are properly defined. Also check the parameters used in the start command to ensure that the ID provided is the same one used to configure the adapter. If the event class is in any filter entry in the configuration file, it is not sent to event server. The administrator who started the adapter must have the required roles if you are running the TME version of the adapter. For a TME adapter, running the odstat command can offer some clues as to what failed.
- If the reception log has a PARSING_FAILED error, the BAROC definition of the class does not match the event that is being received from the adapter. Usually the error messages pinpoint the problem.
- If the previous steps do not indicate any problem and you do not see the new events in the Tivoli Enterprise Console product, there might be a problem with the event group filters. Make sure the class filters match the classes in the BAROC files.
- Change all /dev/null entries in the .err file to the file name you want. Stop and restart the adapter, send an event through, and then look in the trace file to see what processing was done on the event.
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: September 17, 2009