[16296] in Athena Bugs
Re: sun4 8.2.9: syslogd is six feet under?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Sep 4 15:24:04 1998
To: Jonathon Weiss <jweiss@MIT.EDU>
Cc: Dan Winship <danw@MIT.EDU>, John Hawkinson <jhawk@MIT.EDU>, bugs@MIT.EDU
In-Reply-To: Your message of "Fri, 04 Sep 1998 13:41:53 EDT."
<199809041741.NAA13107@speaker-for-the-dead.mit.edu>
Date: Fri, 04 Sep 1998 15:23:54 EDT
From: Greg Hudson <ghudson@MIT.EDU>
>> From looking at the Solaris syslogd source, there might be race
>> conditions where sending a SIGHUP and then another well-timed signal
>> after that would kill it. But I can't see how newsyslog would end up
>> sending two signals either.
> I'm not sure, but I think if newsyslog rolls over multiple logfiles,
> it migth HUP syslogd twice, but it might be more clever than that.
syslogd under Solaris 2.6 processes signals synchronously. I think
Dan is wrong about the signal race, but I wouldn't expect syslogd to
go down on a SIGUSR1 after init() has been called.
Do we have anything else (e.g. timing) to correlate the syslogd deaths
with newsyslog? I think we can discount the process accounting
information at this point (which is irritating), and look for a core
dump condition in the HUP handling code, assuming we think newsyslog
is causing the deaths.