boot ordering and syslogd

[Sam Leffler]

M. Warner Losh wrote:
> In message: <47E81DD1.8050205 at errno.com>
>             Sam Leffler <sam at errno.com> writes:
> : Doug Barton wrote:
> : > Sam Leffler wrote:
> : >> I tried to use syslog to debug an issue with dhclient and noticed 
> : >> that syslogd is started too late for it to work.  This is because 
> : >> dhclient operates in a chroot jail so must setup it's connection to 
> : >> syslogd before privsep work is done.  This seems like a general 
> : >> problem and one that should be fixed.
> : >>
> : >> Anyone got an idea how to correct this?
> : >
> : > It's a chicken-and-egg issue because if you need the network to do 
> : > remote syslog'ing (or syslog'ing to an NFS partition, etc.), you need 
> : > the network up first.
> : >
> : > What I've done in similar situations is to modify a copy of 
> : > dhclient-script to spit out data to a text file. If you need something 
> : > more robust you could always change the ordering locally. If you need 
> : > help with that just let us know.
> : 
> : Er, this is a problem that needs to be fixed; not hacked around w/ local 
> : mods.  We are losing logging that makes diagnosing problems hard.
> 
> Yes.  We need to fix syslogd to be able to start before the network
> or even FS are mounted and have the only thing that goes 'bad' be the
> data to the missing data sinks (disk, network, etc).  A quick fix to
> this would be to have syslog get a HUP after each of these events and
> start syslogd just as soon as /usr is mounted.

Yes, I agree changing syslogd may be best even if we can shuffle the 
order of rc scripts.  It might not be too bad to have syslogd buffer 
msgs until the sink (e.g. log file) is available (maybe use a ring 
buffer to limit resource use).  It might not be too bad to just stat for 
the sink on each received msg since this should hopefully be a very 
short window.

If we don't change syslogd then we'd need to change the client code 
which seems much more complicated.

	Sam