The
information provided applies to the Informix Server Version 11.70.xC2
and later.
The processes of a running Informix Warehouse Administrator instance typically are producing various informational messages that are handled via the system logging mechanism. On a normally configured Linux system, these messages are directed to the file /var/log/messages. Traditionally, this is the place for system messages and therefore it may be convenient to redirect the messages of the accelerator to a different location. For one, this probably helps to unclutter the file /var/log/messages, but it can also avoid running out of disk space for the file system where this file resides.
Depending on the distribution and version of Linux in use, different implementations of system logging are available, each with its specific method of configuration. Therefore, in this blog entry I will describe the method for the most common and basic system logging implementation, the syslogd (see also the manpage for syslogd(8) ). The examples have been tested on Red Hat Enterprise Linux Server release 5.5 (Tikanga) with version 1.4.1 of syslogd. Red Hat Enterprise Linux Server release 6.0 (Santiago) uses the rsyslogd as preferred implementation for system logging. The configuration file for rsyslogd is /etc/rsyslog.conf, which is in its default structure almost identical to the configuration file of syslogd. Therefore the description below can also be applied to a standard configuration of the rsyslogd implementation.
The syslogd implementation of system logging offers several so called 'facilities'. Examples of such facilities are 'auth', 'cron', 'daemon', 'kern', 'mail', 'local0' through 'local7', to name a few. For each facility the system logging can be configured by several levels, e.g. 'debug', 'info', 'warning', 'err', etc. The configuration of the facilities with their levels includes also the destination for the messages, usually files like /var/log/messages. The configuration of syslogd is in file /etc/syslog.conf (see also the manpage syslog.conf(5) for more information). An application like the accelerator has to specify the facility and the level for any messages sent to the system logging.
The following actions normally require root access, so all things should best be done as user 'root'.
The Informix Warehouse Accelerator uses the facility 'local6' for all its messages sent to the system logging. In order to change the destination for all these messages, no matter what is their level, this 'local6' facility needs to be configured in file /etc/syslog.conf. If there is no configuration for the 'local6' facility listed in the configuration file, then the default message destination is /var/log/messages. To change this, two things need to be done in /etc/syslog.conf:
- Entries that apply to all facilities are denoted by an asterisk
wildcard before the dot. An example is the following line:
*.info;mail.none;cron.none /var/log/messagesThis tells the system logging to put all messages of level 'info' coming from all facilities ( *.info ) into /var/log/messages, but not messages from facilities 'mail' and 'cron'.
In this line, the facility 'local6' now also must be specified to exclude its messages from going to /var/log/messages. The changed line will look like this:
*.info;local6.none;mail.none;cron.none /var/log/messages - Assuming that until now there is no configuration for facility
'local6', a new line has to be added to the file for this facility.
Using the asterisk wildcard for the level, we configure for all
messages of facility 'local6' that they be directed to the specified
destination file. The file name has to be specified with the
absolute path, and if it is not owned by user 'root' it must at
least be writable for user 'root'. (This sometimes is not guaranteed
for remote file systems, e.g. mounted via NFS.)
local6.* /var/log/iwalogThe above line will cause all messages for facility 'local6' to be sent to file /var/log/iwalog instead of the default /var/log/messages.
With this the simple configuration for facility 'local6' is complete.
In case there are more configuration lines that apply to all facilities,
i.e. with the asterisk wildcard before the dot, then they should also be
changed as above by adding the ;local6.none specifier to
them.
In order to make the new configuration effective, the syslog daemon has to read the new configuration file. This is achieved by restarting the syslog daemon process, named syslogd. Normally it is sufficient to send this syslogd process the hangup signal upon which it will do the required restart and thus read the new configuration file.
- In order to send a signal to the syslogd process, the process
ID of that process needs to be determined, e.g. using the ps
system utility in the following way:
% ps -ef | egrep -v grep | egrep syslogd
root 2037 1 0 Jun29 ? 00:00:01 syslogd -m 0
%
The ID of the syslogd process in the example is 2037.
- To send the hang up signal to this process, the kill system
utility is used, specifying the signal by its name SIGHUP:
% kill -SIGHUP 2037
%
To check that the system logging daemon really is restarted, a glance at /var/log/messages can be done:
% tail /var/log/messages
Oct 18 ...
Oct 18 11:48:14 <hostname> syslogd 1.4.1: restart.
%
With the above configuration now effective, all future messages from the Informix Warehouse Accelerator should be redirected to the file /var/log/iwalog.
In a following blog entry I will briefly describe the necessary steps when using the syslog-ng implementation ("-ng" for "new generation"), an implementation widely used on SUSE Linux Enterprise Server.
