Logging bootscript output

Vladimir A. Pavlov pv4 at bk.ru
Fri Feb 23 00:51:29 PST 2007

On Friday 23 February 2007 00:14, Bruce Dubbs wrote:
> Vladimir A. Pavlov wrote:
> > 2. May be it would be better if /etc/rc.d/rc (I mean the main rc
> >    script. I don't remember how it's called in LFS) will run each
> >    bootscript using
> > 
> > script_name 2>&1 |tee -a /var/log/bootlog
> > 
> >    rather then simply
> > 
> > script_name
> I thought about this, but it is possible that /var is not mounted early
> in the boot process, however using my script to buffer messages might work:
> script_name 2>&1 |tee /dev/bootlog

I missed that.

Though, if a system hangs between the filesystems needed for logging
messages (/var) have been mounted R/W, and login prompt I'd like to be
able to boot, for example, from LiveCD and look through the bootlog to
determine the failure reason.

That means we must flush write buffer to a disk as soon as possible.
IOW we cannot make two loops in the bootlog.sh, the first being for
"collecting" boot messages while the second being for actual writing
them to a file (as you suggested). In this case if the system hangs
when the first loop is in action we will see no messages in the

> The only minor problem I see is that tee would need to be moved from
> /usr/bin to /bin.

FHS says "The contents of the root filesystem must be adequate to
_boot_, restore, recover, and/or repair the system." so I see no
problem with moving tee to /bin if we need it during system boot.

> >    Though, I don't know if this will work as expected if using C-s/C-q
> >    during system boot to stop/continue service starting (using these is
> >    very useful for viewing messages "on-line" if something goes wrong
> >    upon boot). In general, I don't know what if a user need to interact
> >    with a system (for example, operate with fsck in case of a
> >    filesystem crash) when bootscripts use tee.
> don't know either.  It would require testing.  However, we are not
> changing input at all, so C-s/C-q should stop the process.

I've just tried this, the problem actually exists. If we run something
like "./script.sh |tee file" then pressing C-s stops tee, not

A user presses C-s and messages stop. He/she thinks ./script.sh is
stopped but actually the stopped program is tee. While ./script.sh is
running and printing messages tee is stopped and unable to read and
write these messages. When the user presses C-q he/she will see _all_
the messages ./script.sh has been printing since pressing C-s.

So, using tee in the way I suggested is a bad solution. Using your
daemon-like bootlog.sh is much better.

> Actually I was thinking about removing /dev/bootlog as the last step of
> the boot.sh script.  I don't see it needed after a login prompt.

In this case if we have to start/stop any service on a _running_ system
all the messages the corresponding script outputs won't go to the
bootlog. Well, since it is _boot_ log you're probably right, but I
think it would be useful to log somewhere all the messages of
bootscripts even if they are run _after_ boot.

Nothing but perfection

Vladimir A. Pavlov

More information about the lfs-dev mailing list