On Sun, 29 Oct 2000, Stephen Harris wrote:
>Horst von Brand wrote:
>
>> > > 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.
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).
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Sun, 29 Oct 2000, Jesse Pollard wrote:
> On Sun, 29 Oct 2000, Stephen Harris wrote:
> >Horst von Brand wrote:
> >
> >> > > 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.
>
> 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()!
> 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.
> 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.
--------- Received message begins Here ---------
Jesse Pollard <[email protected]>:
> On Sun, 29 Oct 2000, Stephen Harris wrote:
> >Horst von Brand wrote:
> >
> >> > > 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.
>
> 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).
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.