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.
I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.
I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in /etc/hosts
for the server's IP, followed by the short name.
I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like server.northside.chicago.rizzomanufacturing.com
. Who wants to see that in the logs or a shell prompt?
Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.
A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:
/etc/sysconfig/network:
HOSTNAME=rizzo
...
-
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.100.13 rizzo.ifp.com rizzo
-
[root@rizzo ~]# hostname
rizzo
-
/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to
chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot
to directory '/app/upload/ftp/SRRID'
Best Answer
Try using syslog-ng. I ran into a number of problems with syslogd on openwrt. I suspect you are running into the similar problems. See my documentation on using syslog-ng with openwrt. My logging server is Ubuntu running rsyslogd.
Alternatively, you should be able to do the required changes on the logging server using syslog-ng to rerwrite the log message based on the sending server.