Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: solaris 251 & syslogdDave Kinchlea (securityKINCH.ARK.COM)
Sat, 15 Nov 1997 11:12:21 -0800
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Aleph One: "CERT Vendor-Initiated Bulletin VB-97.13 - GlimpseHTTP.WebGlimpse"
- Previous message: Charles M. Hannum: "Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug:"
- Next in thread: Michael Helm: "Re: solaris 251 & syslogd"
On Sat, 15 Nov 1997, M Shariful Anam wrote: > 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