Re: new inetutils package with better syslogd
> Someone cares to syslogify the Hurd now?
Oh yeah, I forgot to answer this part. The main issue here is making sure
we use a highly robust way of getting the messages out without blocking,
both early during boot-up or any time things get badly frotzed.
syslog (openlog) has LOG_PERROR and LOG_CONS to get messages out when
syslogd is not running, and that suffices on Unix writing to the console
never blocks undesireably unless the whole system is scrod.
In the Hurd, it's a different story. During boot, the terminal server is
not yet running at all. Also, At any time, a bad system problem could make
attempts to write to or open /dev/console fail or (worse) block. The
equivalent "safe thing" is writing to the Mach "console" device directly.
Currently, the essential servers open the Mach "console" device directly
and do their output to that (via a special stdio stream made with
mach_open_devstream). The bootstrap filesystem (libdiskfs), init, and proc
do this; auth doesn't, but in fact auth is so simple that it never has
anything to print after initial startup. It is vital that these servers
never risk blocking on any other server when writing their error messages.
(They already depend on the kernel and the pagers backing their memory,
i.e. the default pager and the bootstrap filesystem. Those are unavoidable.)
Probably the right thing to do is put a new Hurd-specific implementation of
syslog in libc. This can use Mach IPC directly with low-level options to
ensure that it doesn't block badly trying to talk to syslogd, and it can
implement LOG_CONS using the Mach console device directly when possible.
Such a new implementation is unlikely to go into libc 2.1, it will have to
wait for 2.2.
An improved syslog would add robustness to every program using syslog and
so is probably ultimately desireable regardless. But there is another
notion that comes to mind for the essential servers. I am still ambivalent
about this idea.
The idea is to use the "kmsg" kernel device for the essential servers'
messages as well as the kernel's. We add support for opening the "kmsg"
device for writing, to allow user messages to be appended to the internal
buffer the same way as kernel messages are. The essential servers can then
use this device to write their error messages; because it is a kernel
device that cannot block, they can use it as freely as they would the Mach
console device. When and if klogd and syslogd run, they will suck up the
messages from the essential servers along with the kernel messages. Since
the kmsg device is a nonblocking device with a fixed-size internal buffer
used as a ring, this is most like what happens on Unix (and Linux). It
also has the same properties that you could conceivably arrange to retrieve
a kmsg buffer from memory on warm reboot after a crash, and see the dying
messages from both servers and kernel.
I'm leaning away from this idea though. It just seems non-Hurdy.
Reply to: