Re: Log handling
On Thu, Sep 22, 2005 at 09:45:34AM +0200, Joey Hess wrote:
> Colin Watson wrote:
> > Once di-utils 1.13 makes it into initrds, I'd like to start converting
> > udebs to use this. I think it would be reasonable to leave just the
> > debootstrap log in /var/log/messages so that it shows up on tty3, and
> > send pretty much everything else to tty4.
> I've done a pass through the tree and fixed most everything that
> wrote to /var/log/messages to log to syslog, mostly using log-output.
> Haven't uploaded the udebs yet.
Cool! Thanks for beating me to the punch on this one.
> (I find it's easy to forget to pass the first parameter to log-output,
> at least early in the morning. I hope I caught all such mistakes.)
Mmm, yes. Maybe I should have done that differently, but it's probably
too late now ...
> I left base-installer alone, however I don't know if there's any point
> in making it be a special case. To the user reading the logs it's not
> differentiable from the rest of the installer; developers reading the
> logs should find it easy to find the debootstrap bits.
Well, partly it was just to have something to do with tty3 ... I guess
seeing the debootstrap log in real time isn't as useful to users as it
used to be now that base-installer has a better progress bar.
I don't know what else to put on tty3 if we ditch /var/log/messages.
> Also, converting this in localechooser to use log-output has defeated
> if chroot /target/ /usr/sbin/validlocale $LOCALE \
> >> /target/etc/locale.gen 2>> $LOG ; then
I've added a --pass-stdout option to log-output to send just stderr to
syslog, so that this becomes:
if log-output --pass-stdout chroot /target/ /usr/sbin/validlocale $LOCALE \
>> /target/etc/locale.gen; then
(Don't look too hard at the implementation in case it melts or
something, though. Ugh.)
> And this kind of thing is made perhaps a bit too hard to do with
> log-output, so I left some instances of it unchanged in partconf and
> mkswap %s >/dev/null 2>>/var/log/messages
The same can be done with this, but I've left it alone for now until
--pass-stdout's in the initrds. Obviously that didn't matter in the case
> Also, I'm not sure if log-output is intended to be able to take
> arbitrary shell expressions as arguments, or just a simple program+args.
> The current implementation might(?) allow the former but the docs
> suggest it might be intended to be limited to the latter, so I didn't
> feel comfortable converting this bit in preseed to use it yet, since
> $command can be an arbitrary shell expression.
> eval $command >>/var/log/messages 2>&1 || code=$?
The intent is program+arguments, but 'eval $command' is really just
program+arguments in that sense, so that should be fine. I've used "$@",
so log-output shouldn't do anything that requires extra quoting, and
e.g. literal semicolons in $command will be preserved and passed
~ $ set id \; echo foo
+ set id ; echo foo
~ $ "$@"
+ id ; echo foo
BusyBox v1.00-pre10 (Debian 20040623-1) multi-call binary
Usage: id [OPTIONS]... [USERNAME]
Still, obviously something like preseed probably wants some testing
Colin Watson [firstname.lastname@example.org]