Configuring the syslog daemon | KCML Reference Manual

KCML uses the Unix syslog to log warnings, error messages and auditing information. Messages can also be reported by applications using the WRITE LOG statement or, for shell scripts, the kwritelog utility. In exceptional circumstances KClient will directly raise log messages on its server's syslog.

Message formats.

Messages written to syslog are prefixed with the message level, program path name, user name & process ID:-

KCML: ERROR /usr/local/kcml/kcml[fred,31854]: Dumping program state to file /user1/app/panics/panic31854.xml

From build 22236 of KCML 6.20 & 7.15 (or later) a Universally Unique Identifier (UUID) will be included in the syslog message too.

KCML: ERROR /usr/local/kcml/kcml[fred,f3e7ea2e-a543-460c-b404-fd482665c27c,31854]: Dumping program state to file /user1/app/panics/panic31854.xml

For KCML processes this is the same UUID that is stored in the process's entry in $PSTAT.

Configuring the syslog daemon.

What happens to a log entry is determined by the configuration file /etc/syslog.conf that the syslog daemon reads on starting up. This is an ASCII text file that can be edited with any editor. Blank lines are ignored and lines in which the first nonwhite character is a # are treated as comments. The configuration file can filter by facility and priority level and can write the message to a logfile, write to the console screen or redirect to another server. KCML 6.00 and later uses a facility codes of LOG_LOCAL1 & LOG_LOCAL2, while KCML 5 uses the LOG_USER facitity. Both versions use priority levels of LOG_INFO, LOG_WARNING and LOG_ERR. KClient also uses the LOG_DEBUG level for GPF stack dumps.

A configuration entry in this file is composed of two TAB-separated fields, one for the selector and one for the action. The selector field contains a semicolon-separated list of priority specifications of the form facility.level where facility is a system facility, or comma-separated list of facilities, and level is the minimum severity of the condition being logged. There are a number of built in codes such as kern, mail, etc. KCML 6 uses the local1 and local2 facility codes, while KCML 5 uses the user facility code for their messages. The facility symbol * can be used to represent all facilities and the level none means do not send messages from the indicated facility to the selected file. So for example, a selector of *.debug;mail.none will send all messages except mail messages to the selected file.

The action field indicates where to forward the message. Values for this field can have various forms of which only two are relevant to a KCML site, viz:

A filename, beginning with a leading slash, which indicates that messages specified by the selector are to be written to the specified file. The file will be opened in append mode. The syslog daemon on AIX will not create a new file, you will need to do that manually .
The name of a remote host, prefixed with an @, e.g. @server, which indicates that messages specified by the selector are to be forwarded to the syslogd on the named host.

A KCML site could use

local1.info;local2.info;user.info   /var/adm/log/kcml.log

to pick up all KCML messages.

To get KClient dumps it should log

*.debug                 /var/adm/log/debug.log

For more about syslog configuration see the man page for syslogd on your system. Many Linux systems now use enhanced versions of syslog:

syslog-ng - OpenSUSE 11.1, SuSE Enterprise Server R3
rsyslogd - RedHat/CentOS/Oracle Linux 6, Debian 5 & later, Fedora Core 10 & later, OpenSuSE 11.2 & later, Ubuntu 9.10 & later, SuSE Enterprise Server 12

Most rsyslogd implementations support configuration file fragments that are automatically included from the /etc/rsyslogd.d directory.
For example, creating the file /etc/rsyslogd.d/kcml.conf with the contents:-

# KCML system log messages
local1.info;local2.info;user.info   /var/log/kcml.log

is the preferred alternative to changing /etc/rsyslog.conf directly.

Modern versions of syslog-ng also support configuration fragments from a /etc/syslog-ng/conf.d directory.
For example, creating /etc/syslog-ng/conf.d/kcml.conf with the contents:-

# syslog-ng equivalent of
#local2.notice			/var/log/kcmlaudit.log
#local1.info;local2.notice	/var/log/kcml.log
filter f_kcmlaudit	{ level(notice) and facility(local2) };
filter f_kcmllog	{ level(notice) and facility(local2) or level(info) and facility(local1) };
destination kcmlaudit { file("/var/log/kcmlaudit.log" suppress(30) perm(0644)); };
log { source(src); source(chroots); filter(f_kcmlaudit); destination(kcmlaudit); };
destination kcmllog { file("/var/log/kcml.log" suppress(30) perm(0644)); };
log { source(src); source(chroots); filter(f_kcmllog); destination(kcmllog); };

Audit log

Syslog can also be configured to record auditing information including:

Users logging in and out
Execution of SHELL statements
Signalling of KCML processes
Change of an expired password
Impersonating another user when calling 'KCML_Impersonate()

These log messages are reported on the LOG_LOCAL2 factility at LOG_NOTICE priority, so can be recorded in a seperate log file. However, to syncronize audit messages with normal KCML syslog messages it is advisable to include them in the standard KCML syslog as well:

# KCML system log messages
local1.info;local2.info		/var/log/kcml.log
local2.notice			/var/log/kcmlaudit.log

Log rotation

As logs get bigger with time you may need rotate the logs. The method of log rotation is dependent on the type of Unix system.
AIX5 specifies additional keywords for /etc/syslog.conf that control the rotation, and optional backup, of log files.
Many Linux implementations use logrotate to manage many operating system log files. The list of syslog files is usually stored in /etc/logrotate.d/syslog.
Other Unix systems could use a cron script to accomplish log rotation.