Re: util-linux seems to have /sbin/fsck
On Tue, 13 Jan 2004 15:50:24, Theodore Ts'o wrote:
> On Mon, Jan 12, 2004 at 09:59:29PM +0000, Miquel van Smoorenburg wrote:
> > The reason I haven't integrated logsave into the current scripts
> > is that bootlogd does basically the same. But bootlogd isn't
> > perfect - it should be replaced with something better. Perhaps
> > the logsave approach, using pty's, in a client/server setup
> > over a named pipe ? /dev/bootlogd| ? A few simple hooks in
> > /etc/init.d/rcS and /etc/init.d/rc and this would work. Those
> > hooks could also trivially be used for dummy-mode redhat-style
> > "Starting apache .. [OK]" output.
>
> Why use pty's? logsave just uses pipes, because nothing in
> /etc/init.d scripts should be stoping to ask the user questions.
> Certainly no fsck script should. In addition, using pipes instead of
> pty's avoids some of the problems you mentioned with bootlogd.
Yes, that's probably right. The filesystem checking scripts can launch
a shell if fsck fails but they can use /sbin/sulogin -t /dev/tty
> The other reason why I think the fsck scripts should be saved in
> another file is that normally they are much less verbose than the full
> boot logs, and while you might want to only save only a few boot
> sessions, fsck logs should be saved for much longer, since often times
> they can be critical for reconstructing what happened.
For you maybe, but in reality I have never heard of someone reconstructing
data from fsck logs ? You probably need an in-depth knowledge of the
ext2/ext3 on-disk format to be able to do something useful..
> I don't understand your whole proposal of client/server setup with
> bootlogd, so perhaps you have a more elegant solution in mind. But at
> first listening, it sounds a lot more complicated than it needs to
> be....
Well, you can't log anywhere until at least / and /var have been checked,
so what do you do with the data in the mean time ? My idea was to run
a bootlogd that basically does the same as bootlogd now, it reads data,
and keeps it in a ring-buffer in memory until it can write to a logfile.
Only it would not redirect /dev/console but simply listen to /dev/bootlogd.
The "client" I'm talking about would create the pty/tty pair, launch the
/etc/init.d/service and redirect I/O to the /dev/bootlogd pipe and perhaps
/dev/console. It could also timeout on writing to /dev/bootlogd so that if
something goes wrong at least the system will boot (albeit a bit slower).
The advantage of a tty/pty pair is that you can forcibly close and free
the tty after the /etc/init.d/service has run, a simple output redirect
to the /dev/bootlogd pipe will probably cause some services to keep that
pipe open forever.
One problem is - how do you detect that bootlogd is running? Can I
assume that Unix sockets are always available (syslogd depends on it,
at least, so probably yes) .. in that case a simple connect() will return
ECONNREFUSED if there is no bootlogd. Hmm that would be acceptable.
But I haven't implemented any of this yet, it's just that I started thinking
about it because bootlogd is a nice hack but the console-redirect trick
feels unclean.
Mike.
Reply to: