Subject: Re: raidframe parity always dirty after reboot
To: Matthias Buelow <mkb@mukappabeta.de>
From: Greg A. Woods <woods@weird.com>
List: netbsd-users
Date: 04/28/2003 14:54:45
[ On Monday, April 28, 2003 at 19:09:14 (+0200), Matthias Buelow wrote: ]
> Subject: Re: raidframe parity always dirty after reboot
>
> Maybe some runlevel-style scheme would really be best then;
> so that halt/reboot just send the appropriate signals to init
> which then shuts down running the respective runlevel scripts.
Well, ... :-)
> I'm just not comfortable at all with halt or reboot (which I
> normally use everywhere since I rarely have to inform users
> via shutdown -- and shutdown is just a user-information wrapper,
> read the manpage) when halt/reboot don't do the full show.
I've always been a little bit uncomfortable with the fact that halt(8)
and reboot(8) signal 'init'. I would almost rather that they just talk
to the kernel and tell it to do the appropriate thing and assume that
userland has taken care of its own. Indeed this has been the more
traditional implementation (in concept at least, if not always in
practice), practically everywhere but in BSD.
In any case I think it should be one way, or the other, not some
hodge-podge mixup. The tricky part is keeping the shutdown procedures
attached to the TTY from which "shutdown" (or whatever), has been
invoked, if indeed that's what's desired (there is an arugment for
having "init" run /etc/rc.shutdown).
I think we've nearly got it ``Right(tm)'' or at least as good as can be
on all fronts, in NetBSD. The only problem is that old habits are hard
to break.
"shutdown" should be what every administrator always uses by default.
It calls "reboot" or "halt" as and when appropriate. Admins should
simply learn not directly use "reboot" or "halt".
Mabye there should be a "-q" option to shutdown, meaning "quick &
quiet". It would make the "time" operand optional and would not send
any warnings to anyone. Mabye that would help wean admins away from
using "halt" and "reboot" when they shouldn't....
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>