On Mon, 24 Jul 2000, Christoph Badura wrote:

> One reason for running rc.shutdown is to bring the system into a defined
> state before rebooting.  Killing the shutdown script after an effectively
> random amount of time (with a SIGKILL even!) is not compatible with that goal.
> shutdown(8) has no way to determine whether it is "safe" to kill the
> rc.shutdown process.

I agree. At least, I would like to see a way to disable it ("-T 0"?).
Or better, leave it off by default. After all, "shutdown" doesn't even
use an arbitrary time for the initial delay, so why should there be an
arbitrary time for this?
 
> Also, you have two perfectly viable alternatives to handle the situation:
> a) fix the buggy rc.d script to not hang.

How _would_ you make an rc.d script timeout? Think "umount -a -t nfs"
after the network has gone down.

> b) interrupt shutdown, e.g. by sending a SIGINT.

The motivation is: you're debugging or beta testing a daemon that must
start before the network and sshd and finish after, and it may go
zombie or otherwise act unpredictably, so you want to be sure that the
machine at least reboots. SIGINT won't do, because once the network
goes down, it's too late to recover your shell, so someone would have
to go to the console anyway.

> If you don't care about bringing the system down in an orderly manner
> you have several options already (e.g. use reboot(8) or don't run
> rc.shutdown).  Making it virtually impossible to shut down the system
> in an orderly manner is not acceptable.
> 
> In short, this change is bogus and should be backed out.

Clearly, it's not for everyone. I would be OK with it as long as
there's no timeout by default.



Frederick