• 共享
  • ?
  • 个人档案 ▼
  • 社区 ▼
  • 应用程序 ▼

博客

  • 我的博客
  • 公共博客
  • 我的更新

此社区可以包含贵组织以外的成员。 Informix Warehouse Accelerator

  • 登录以进行参与
2fa81a5c-cb30-4873-b775-1370151e3614 Blog

▼ 标签

▼ 类似的条目

How To Install & Con...

博客: Munshi Hafizu...
mhhaque 2700012HF4
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

Linux on IBM Z perfo...

博客: Ingolf's z/VS...
Ingolf24 120000DRN3
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

Long term history co...

博客: Application P...
SushamaK 1100006DS0
更新时间
共有 4 个人对此内容点赞点赞的项目 4
无评论评论 0

Compile PHP, Informi...

博客: developerWork...
Gadde_Radhika 50J9GYTSQP
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

2018 VM Workshop - E...

博客: Ingolf's z/VS...
Ingolf24 120000DRN3
更新时间
共有 0 个人对此内容点赞点赞的项目 0
无评论评论 0

▼ 归档

  • 2015年12月
  • 2015年11月
  • 2015年4月
  • 2015年3月
  • 2014年12月
  • 2014年9月
  • 2014年7月
  • 2014年6月
  • 2014年5月
  • 2013年10月
  • 2013年9月
  • 2013年6月
  • 2013年5月
  • 2013年4月
  • 2012年9月
  • 2012年7月
  • 2012年6月
  • 2012年5月
  • 2012年4月
  • 2012年3月
  • 2012年2月
  • 2011年11月
  • 2011年10月
  • 2011年9月
  • 2011年8月
  • 2011年7月
  • 2011年6月
  • 2011年5月
  • 2011年4月
  • 2011年3月

▼ 博客作者

Informix Warehouse Accelerator

查看所有条目
单击此按钮可以刷新整个页面。用户可以转至“条目列表”区域查看新内容。) 条目列表

Informix Warehouse Accelerator: Redirecting Messages (1)

martinfu 060000BPWC | | 标签:  accelerator warehouse system_logging linux im syslog informix messages ‎ | 7,718 次访问

Blog Content/Topics List


Icon: IWA Logo TruckThe 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/messages

    This 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/iwalog

    The 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.


Blog Content/Topics List

  • 添加评论 添加评论
  • 编辑
  • 更多操作 v
  • 隔离此条目
通知其他人
notification_ex

发送电子邮件通知

隔离此条目

deleteEntry
duplicateEntry

标记为重复项

  • 上一个条目
  • 主页
  • 下一个条目
“博客条目”的订阅源 | “博客评论”的订阅源 | 此条目评论的订阅源