Syslogd configuration problem

Self-answer. It seems to be impossible to imitate syslogd behavior. After a lot of experiments, I provide updated snapshot of my research/guesses on syslog-ng options:

options {
        #####################################################################
        ### the flow of decisions for hostnames, syslog-ng 1.6.8:

        use_dns(yes);           # yes = first resolve the IP in $HOST_FROM (the message sender)

        keep_hostname(no);      # no = ignore $HOST embedded in the message (rare); overwrite $HOST with $HOST_FROM
                                #   note: RFC3164 allows embedding short hostname or IP, not FQDN

        use_fqdn(yes);          # yes = expand everything to FQDN, including local name
                                # Note syslogd behaviour is incompatible: use FQDN, but strip local
                                #   domain + strip "-s" domains + strip domains for "-l" hosts

        chain_hostnames(no);    # no = keep $FULLHOST same as $HOST; 
                                #   do not expand $FULLHOST into either "src@$HOST" for localhost, 
                                #   or to "$HOST/$HOST_FROM" for remote client

        #long_hostnames(no);    # synonym of chain_hostnames

        ### with default template, the resulting $FULLHOST is written to log
        #####################################################################

        check_hostname(yes);    # invalid chars?

        sync(0);                # sync immediately
};

I've found out that messages from my remote systems probably do not have hostname embedded, and this causes keep_hostname to be of no use.

Since the link no longer works, I've changed it to the Internet Archive and quoted a portion of the article here:

named-pipes

later versions of syslog have support for writing to named-pipes. a named-pipe is a special type of file that implements a simple fifo stream, allowing processes to talk to each other. we'll exploit named-pipes to implement real-time messaging between syslog and our mailer. in our example, we'll take all critical messages written to the local0 facility and (in addition to logging) send them to the mail recipient, fireman@example.com.

configuring syslog to write to a named-pipe

first, create a named-pipe for critical messages, for example:

# mkdir /etc/syslog.pipes
# mknod /etc/syslog.pipes/criticalMessages p
# chmod 600 /etc/syslog.pipes/criticalMessages

next, configure syslog to log all critical messages written to the local0 facility to this pipe. add the following statement to your syslog.conf file.

local0.crit   |/etc/syslog.pipes/criticalMessages

sending out messages

the final step is to mail out any messages that are written to the pipe. you can do this with a simple shell script. i've included an example below, let's call it /usr/bin/syslogMailer:

#!/bin/bash

# syslogMailer: a script to read stdin and turn each line into an alert
# email typically this is used to read a named-pipe written to by syslog
#
#   example usage: syslogMailer < /etc/syslog.pipes/criticalMessages
#

alertRecipient="fireman@example.com"      # the mail recipient for alerts
TMOUT=1                                   # don't wait > 1 second for input

# process each line of input and produce an alert email
while read line
do
   # remove any repeated messages
   echo ${line} | grep "message repeated" > /dev/null 2>&1
   if test $? -eq 1
   then
      # send the alert
      echo "${line}" | mailx -s "critical error on syslog" ${alertRecipient}
   fi
done

daemon vs cron?

you'll notice that i've included the following line in the script:

TMOUT=1                                 # don't wait > 1 second for input

this line specifies a one second timeout for the bash builtin, read. the script therefore runs to completion after processing one batch of zero or more messages. this allows you to schedule it in cron to run, say, every 5 minutes with a statement like:

# m h  dom mon dow   command
0-59/5 * * * * /usr/bin/syslogMailer < /etc/syslog.pipes/criticalMessages > /dev/null 2>&1

alternatively, if you'd like to turn this script into a log-running daemon that will sit in an endless loop and send out messages as soon as log statements arrive, remove the timeout line and surround the read statement with an while-true loop i.e.

# process each line of input and produce an error message
while :
do
   while read line
   do
      [...]
      # send the alert
      echo "${line}" | mailx -s "critical error on syslog" ${alertRecipient}
   done
done

the daemon approach is a little more efficient and sends out emails synchronously. it has the disadvantage that if your daemon terminates unexpectedly, alerts will stop until the daemon is restarted. the cron based implementation is arguably more robust in this regard. the cron approach also allows you to batch up notifications into n minute chunks. 5 minutes in our example cron file above.