Subject: Re: CVS commit: basesrc: shutdown -T
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 07/24/2000 11:30:17
[ On Sunday, July 23, 2000 at 23:16:08 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: CVS commit: basesrc: shutdown -T
> 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?
In this case the high-level timeout is *always* wrong. It should never
be done in shutdown.
> > 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.
Been there, done that! It happens all the time to me! ;)
I contend though that the bug is in umount. It may time out evenutally
but I've never had enough patience, even when I've gone out to dinner
while waiting for it. I considered changing it to be a forced umount
when NFS is involved, but I haven't thought that through yet, nor have I
even tested it yet.
> Clearly, it's not for everyone. I would be OK with it as long as
> there's no timeout by default.
No, it's never right. There maybe should be a generic timeout in the
rc.d mechanisms that any "stop" command can *optionally* use. However
it's *never* right to timeout the entire process when the fault is only
in a handful of scripts. All scripts *must* be given the chance to run
(unless of course the operator interactively interrupts the process).
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>