mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@cats-chateau.net>
To: Stephen Harris <sweh@spuddy.mew.co.uk>,
	vonbrand@sleipnir.valparaiso.cl (Horst von Brand)
Cc: linux-kernel@vger.kernel.org
Subject: Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
Date: Sun, 29 Oct 2000 10:35:27 -0600	[thread overview]
Message-ID: <00102910423100.15754@tabby> (raw)
In-Reply-To: <200010290920.JAA03918@spuddy.mew.co.uk>
In-Reply-To: <200010290920.JAA03918@spuddy.mew.co.uk>

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: pollard@cats-chateau.net

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-10-29 16:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <G31psL.73r@spuddy.mew.co.uk>
2000-10-28 19:36 ` Stephen Harris
2000-10-28 23:51   ` Horst von Brand
2000-10-29  9:20     ` Stephen Harris
2000-10-29 16:35       ` Jesse Pollard [this message]
2000-10-29 17:18         ` Stephen Harris
2000-10-30  0:45           ` Igmar Palsenberg
2000-10-30 14:17           ` Jesse Pollard
2000-10-29 18:48         ` James Sutherland
2000-10-30 14:06         ` Jesse Pollard
     [not found] <Pine.LNX.4.04.10010261143060.14708-100000@beaker.bluetopia.net>
2000-10-27 22:15 ` Igmar Palsenberg
     [not found] <s5gy9zbzkz3.fsf@egghead.curl.com>
2000-10-27 22:10 ` Igmar Palsenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00102910423100.15754@tabby \
    --to=pollard@cats-chateau.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sweh@spuddy.mew.co.uk \
    --cc=vonbrand@sleipnir.valparaiso.cl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®