OOBC Syslog files

Edit online

Use this information to set the syslogMessageSaverFile, and to understand the rollover strategy for syslog files.

Description

You can specify a location to which the syslog files should be saved to. The syslog filepath is determined by the syslogMessageSaverFile parameter in the oobc.properties.xml property file. You should enter an appropriate filepath for this parameter, e.g./opt/IBM/tivoli/netcool/ncm/. This will be the location where all syslog files will be saved to.

The OutOfBandChange daemon will always parse the syslog file specified in the oobc.properties.xml property file. If, as can happen in a Unix environment, the syslog file is rolled over by an administrative utility, then the OutOfBandChange daemon will also attempt to rollover to the new syslog file.

This rollover is predicated on the fact that typical syslog administrative scripts will follow a standard procedure:

  1. Remove the oldest syslog file.
  2. From oldest to newest, rename the files to a file name with a larger sequence number.
  3. Open the new syslog file.

If, however, the OutOfBandChange daemon has the current syslog file open for reading while the syslog rollover occurs, there is no indication that this has occurred and therefore the OutOfBandChange daemon will be reading the now old syslog file.

Because of this scenario, the OutOfBandChange daemon will close its syslog file after a certain amount of time has expired with no new updates written to the log file. Then, it will open the syslog file again and wait again for the specified amount of time for updates written to the log file. If no updates occur within that time frame the file is closed and reopened again. This will repeat forever as long as there are no updates to the syslog file within the specified time frame and as long as the OutOfBandChange daemon is running.

If, however, a syslog file was rolled over from saylocal6.log to local6.1.log and a new local6.log file was created, the daemon will still have the old file open for read operations. Since nothing new is being written to the local6.1.log file, it will eventually be closed by the daemon. The daemon will then attempt to open up local6.log again, this time picking up the newly created (rolled) log file, and continue parsing.