[ 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      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>