syslog() blocks on glibc 2.1.3 with kernel 2.2.x
A message that is not in the archive (sent off-list or not yet received): [email protected]
A lot of talk here has been about syslog and DNS blocking, but the original message mentioned:
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Has this been addressed (and I missed it) or did the question get diverted? If it has been addressed, just please mail me personally to save traffic on the list.
Thanks!
Signature · 9 lines
Stephen Harris
[email protected] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/Quoted 6 lines · [email protected] (Stephen Harris) said:
A lot of talk here has been about syslog and DNS blocking, but the original message mentioned:
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new?
Signature · 6 lines
Horst von Brand [email protected] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Horst von Brand
Quoted 3 lines
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new?
OK, let's go a step further - what if syslog dies or breaks in some way shape or form so that the syslog() function blocks...?
My worry is the one that was originally raised but ignored: syslog() should not BLOCK regardless of whether it's local or remote. syslog is not a reliable mechanism and many programs have been written assuming they can fire off syslog() calls without worry.
Stephen Harris
[email protected] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Stephen Harris
Quoted 6 lines · Horst von Brand
Quoted 3 lines
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new?
Quoted 7 lines
OK, let's go a step further - what if syslog dies or breaks in some way shape or form so that the
syslog()function blocks...?My worry is the one that was originally raised but ignored:
syslog()should not BLOCK regardless of whether it's local or remote. syslog is not a reliable mechanism and many programs have been written assuming they can fire offsyslog()calls without worry.
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a few seconds (depending on the log rate...).
I do believe that restarting syslog should be possible... Perhaps syslog should be started by inetd at the very beginning. Then it could be restarted after an exit/abort.
This can STILL fail if the syslog.conf is completely invalid - but then the system SHOULD be stopped pending the investigation of why the file has been corrupted, or syslogd falls back on a default configuration (record everything in the syslog file).
Signature · 9 lines
------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 1 line
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
( heh... at work on Solaris I monitor 300+ systems, and it's not unusual to find 1 box a week with syslog not running for some reason or another. I can't decide whether it's admin stupidity or bugs in Solaris syslog - of which there are many :-(( )
syslog is not meant to be a secure audit system. Messages can be
legitimately dropped. Applications have been coded assuming that they
will not be frozen in syslog(). Linux should not be different in this
respect. Hmm... it might be nice to be this a system tunable parameter
but I'm not sure the best way of doing that (glibc maybe?)
Stephen Harris
[email protected] http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01708 442043 < for free Usenet access *
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines
Quoted 2 lines
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
In some cases, I find the syslog messages of more importance then a working system. I like to know what's going on on my machines.
Quoted 7 lines
( heh... at work on Solaris I monitor 300+ systems, and it's not unusual to find 1 box a week with syslog not running for some reason or another. I can't decide whether it's admin stupidity or bugs in Solaris syslog - of which there are many :-(( )
syslog is not meant to be a secure audit system. Messages can be legitimately dropped.
I find dropping messages unacceptable.
Quoted 4 lines
Applications have been coded assuming that they
will not be frozen insyslog(). Linux should not be different in this
respect. Hmm... it might be nice to be this a system tunable parameter
but I'm not sure the best way of doing that (glibc maybe?)
I needs to be in glibc, yes.
Quoted 2 lines
Stephen Harris
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Stephen Harris <[email protected]>:
Quoted 4 lines
Quoted 1 line
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
Should because this is the only audit logging facility presently available to Linux.
Quoted 4 lines
( heh... at work on Solaris I monitor 300+ systems, and it's not unusual to find 1 box a week with syslog not running for some reason or another. I can't decide whether it's admin stupidity or bugs in Solaris syslog - of which there are many :-(( )
On these boxes you should be running the audit log. Which has the property of shutting the system down when it is aborted...
Quoted 5 lines
syslog is not meant to be a secure audit system. Messages can be
legitimately dropped. Applications have been coded assuming that they
will not be frozen insyslog(). Linux should not be different in this
respect. Hmm... it might be nice to be this a system tunable parameter
but I'm not sure the best way of doing that (glibc maybe?)
The best way would be to have a true audit daemon that has the property of hanging/shutdown of the system. I would prefer a shutdown to single user mode than a hang. That way I would get a chance to examine the log/restart the daemon and examine the log. Even better would be a way to suspend/checkpoint all processing, switch to a "audit emergency" mode with no network activity allowed, and then examine things. It would provide an option to clean the system and reboot, or restart the audit daemon and resume multiuser mode (resuming all suspended/checkpointed processes).
Once there is an audit daemon then the security messages/alerts, and only those messages, would be sent to it.
That way syslogd is available for non-security related events, and these could be dropped when necessary.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 13 lines · Jesse Pollard
Quoted 12 lines · Stephen Harris
Quoted 6 lines · Horst von Brand
Quoted 3 lines
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new?
OK, let's go a step further - what if syslog dies or breaks in some way shape or form so that the
syslog()function blocks...?
Quoted 7 lines
Quoted 4 lines
My worry is the one that was originally raised but ignored:
syslog()should not BLOCK regardless of whether it's local or remote. syslog is not a reliable mechanism and many programs have been written assuming they can fire offsyslog()calls without worry.It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a few seconds (depending on the log rate...).
No. You should have the OPTION of stopping the machine, if accurate syslog information is more important to you than system functionality. This should also be an OS function, rather than just freezing processes as and when they call syslog()!
Quoted 3 lines
I do believe that restarting syslog should be possible... Perhaps syslog should be started by inetd at the very beginning. Then it could be restarted after an exit/abort.
inetd? I'd have thought init would make a more suitable choice, perhaps with a monitor to lock the machine up or reboot if syslog fails and can't be restored.
Quoted 4 lines
This can STILL fail if the syslog.conf is completely invalid - but then the system SHOULD be stopped pending the investigation of why the file has been corrupted, or syslogd falls back on a default configuration (record everything in the syslog file).
Again, that might be useful in some cases, but certainly shouldn't be the only, or even default, mode.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
--------- Received message begins Here ---------
Jesse Pollard <[email protected]>:
Quoted 21 lines · Stephen Harris
Quoted 9 lines
Quoted 6 lines · Horst von Brand
Quoted 3 lines
Quoted 3 lines
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3, kernel 2.2.x), within a few minutes you will find your entire machine grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself in the foot. Anything _really_ new?
Quoted 7 lines
OK, let's go a step further - what if syslog dies or breaks in some way shape or form so that the
syslog()function blocks...?My worry is the one that was originally raised but ignored:
syslog()should not BLOCK regardless of whether it's local or remote. syslog is not a reliable mechanism and many programs have been written assuming they can fire offsyslog()calls without worry.It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a few seconds (depending on the log rate...).
Quoted 8 lines
I do believe that restarting syslog should be possible... Perhaps syslog should be started by inetd at the very beginning. Then it could be restarted after an exit/abort.
This can STILL fail if the syslog.conf is completely invalid - but then the system SHOULD be stopped pending the investigation of why the file has been corrupted, or syslogd falls back on a default configuration (record everything in the syslog file).
As was pointed out in a separate E-mail: I ment to say "init" instead of "inetd", since inetd can generate syslog messages...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/