From owner-freebsd-audit  Mon Feb 18  1:55:57 2002
Delivered-To: freebsd-audit@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 1C8F737B402
	for <audit@FreeBSD.ORG>; Mon, 18 Feb 2002 01:55:54 -0800 (PST)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa37926@salmon>; 18 Feb 2002 09:55:53 +0000 (GMT)
To: Bruce Evans <bde@zeta.org.au>
Cc: "Todd C. Miller" <Todd.Miller@courtesan.com>, audit@FreeBSD.ORG,
	Chris Johnson <cjohnson@palomine.net>,
	Brian McDonald <brian@lustygrapes.net>
Subject: Re: Syslog hangong on console. 
In-reply-to: Your message of "Mon, 18 Feb 2002 14:04:04 +1100."
             <20020218131837.K4236-100000@gamplex.bde.org> 
X-Request-Do: 
Date: Mon, 18 Feb 2002 09:55:51 +0000
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID:  <200202180955.aa37926@salmon.maths.tcd.ie>
Sender: owner-freebsd-audit@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-audit.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-audit>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-audit>
X-Loop: FreeBSD.ORG

> Using O_NONBLOCK without using tcdrain(3) gives a different kind of
> brokenness.  Unfortunately, David's change to syslog.c gives a perfect
> example of this.

I just explained this to Bruce in private mail. I also confused
Todd, so I think I should probably explain the patch more carefully.
What Bruce says about data getting lost on close with O_NONBLOCK
is true, but in this case this is close to what we want...

Usually, syslog messages are just written to a socket connected to
syslogd. However, if this doesn't work out then syslog itself tries
to write an error to the console directly (ttymsg is not used here).

The bit of syslog(3) that I am patching is only this last attempt
to get the message to /dev/console if everything else has failed.
Before it attempts to do this it has already:

	1) Made sure the socket to syslogd is open,
	2) tried to log the message,
	3) if that fails disconnect and reconnect to
           syslogd and try to send again,

If all this fails, then it tries to open /dev/console, which may
block indefinitely. If it blocks indefinitely, then they system is
more-or-less useless because you cannot run any commands which log
messages (like su).

My hope is that if people can su while syslogd is confused, then
someone will be able to run gdb on syslogd and find out what it
is doing.

	David.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message