Good morning to Miquel and everyone else on linux-kernel.
> Hmm - I now know what goes wrong, I think.
... [ Problem deleted. ] ....
> What happens is that init writes to syslog(), and it hangs in the
> syslog() call. There are lots of prblems with syslogd, but I
> don't know here it comes from - could be syslog() in the lib
> (doubt it), the syslogd, the handling of UNIX sockets in the
> kernel or a combination of it.
I will agree that there are a number of deficiencies in syslogd, I
have been trying to address them over the last few years with the
version of syslogd that is found in sysklogd. We just released
version 1.3 last week. I would be interested in knowing if the
problem persists in this version as well.
The most common problem with syslog messages stalling is the inability
of syslogd to resolve a hostname into an IP address when forwarding of
remote messages is in effect. Even with the needed IP address
definitions in /etc/hosts the library resolver code takes a fair
amount of time to timeout if named is not running locally or if a
remote named is down or inaccessible.
Martin Schulze contributed patches which went into the 1.3 code which
allows for periodic re-trys the address of a remote host cannot be
resolved. This may or may not help with your problem. In any event I
would be interested in knowing if 1.3 helps so that we can begin
looking at the problem for 1.4.
> Another symptom is that you can't login as root the first
> minute after boot - login will hang while trying to syslog().
This tends to be a classic example of syslogd being unable to resolve
a hostname. login attempts to log the fact that a root login is
occurring and stalls because syslogd is unresponsive or cannot forward
the message to its remote host.
> I've fixed it in sysvinit-2.59, ofwhich I keep promising
> it will be out this week :) by not calling syslog() when changing
> runlevels. Fixes the symptom, not the problem.
Agreed, what we need to due is to localize the reason for the stall
whether it be in syslog, syslogd or somewhere in between. I would
pleased to help pin this down and fix the problem.
I am not sure of the stability or the presence of bugs in the version
of syslogd that is found in the linux-utils package. Both versions
trace their parentage back to the original BSD code but I know that I
spent quite a few hours shaking some rather obscure bugs out of what
is known the version in sysklogd.
I know that our version of syslogd fell into disfavor in some camps
because of the inability for it to tolerate tabs in the configuration
file. This feature came from the original Berkeley sources but has
been repaired in the current version. I also know that there was
concern at one point for separating the kernel logging into a separate
program.
I am not sure how the community feels about this but I would like to
strongly advocate that an attempt be made to support one version of
the syslogd daemon. I of course have a strongly vested interest in
our code.
My work with the syslogd sources has convinced me that there are a
number of fairly obscure bugs that can be encountered, especially in
the realm of remote logging. The syslogd source in the linux-utils
may have already addressed this issue. Other than a problem with
missing a null return value in gethostbyname we have had very little
in the way of problem reports with the version 1.3 sources.
I would be interested in whatever comments people may have. The
syslogd daemon, especially in network aware machines, is a fairly
important tool. My desire in all this is to make sure that Linux have
a stable, coherent platform for its system logging requirements.
> Mike.
Greg
}-- End of excerpt from Miquel van Smoorenburg
As always,
Dr. G.W. Wettstein Oncology Research Div. Computing Facility
Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
820 4th St. N.
Fargo, ND 58122
Phone: 701-234-7556
----------------------------------------------------------------------
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.' -- GWW