> On Wed, 12 Nov 1997, Dave Kinchlea wrote:
> | A small point but, with use of the `mark' facility in syslog, and proper
> | monitoring for it, you can and should be able to detect syslogd either
> | dying or refusing to write to files (amounts to the same thing). No ne
>
> hmm.. would you like to illustrate a bit more on it? man page on
> syslog.conf doesn't say much.
Sure
With most (all?) syslogd implementations, there is an internal
facility called `mark'. While I am sure that the actual details of the
mark facility vary from one implementation to another, generally it is
used by syslogd to send a time stamp to the specified file and/or server
at specified time intervals (usually modifiable via command line args) as
long as no other syslog output has been generated since the last MARK.
Assuming you have some real-time monitoring of syslog output, all
you need to do is adjust the monitoring so that you expect to see *some*
output within a specified time, if regular syslog traffic doesn't generate
any (ie: during a slow time), the `mark' facility will. When you do not
receive any output within the specified time, syslogd is down (or perhaps
the loghost and/or network is, in any case time to look into it).
The `trick' here is to remember that many (all?) syslogd
implementations do NOT include the `mark' facility in wildcards. So,
*.debug @sysloghost
in /etc/syslog.conf does NOT forward any mark records. You must include it
specifically:
*.debug;mark.* @sysloghost
>
> Also, logging to the console could be one solution.
Doesn't scale well and it requires humans to do the monitoring. No, this
really isn't a good answer for those who truly need the logging, there is
just no way to automate it. Besides, many of us use a single screen as
console for many different servers.
cheers, kinch