[OpenAFS-devel] Re: bos killed fileserver before it was shut down cleanly.

[Jeffrey Hutzelman]

--On Wednesday, October 13, 2010 05:32:30 PM -0400 Steve Simmons 
<scs@umich.edu> wrote:

> IMHO the basic parameter for this belongs in BosConfig. But it would also
> be very useful to enable an on-the-fly change, ie, you realize the timers
> going to go off in a few minutes and another 10 would see you thru to
> clean shutdown and no salvages. At first glance that'll become less
> important with demand attach, but on second glance demand attach might
> mean we want to make those times hugely shorter. Either way, an on the
> fly change capability would be good. I don't see anything in the bos
> manpages that allows for it to re-read the BosConfig file on the fly, but
> that kind of feature probably wants more general discussion anyway.

The bosserver re_writes_ the BosConfig file on the fly.  The intent is that 
all changes are made by making RPC's to the bosserver.



> Separately, I could see a bos command to do this, somewhat like 'bos
> restarttime' and so forth. Such a command could be very specific to this
> timer, eg,
>
>     bos fsshutdownwait -server <machine name>
>            -time <seconds_to_wait>
>            [-cell <cell name>] [-noauth] [-localauth] [-help]

That's along the right lines, but really should be a bit more general.  I 
should be able to change the timeout, temporarily or permanently, for any 
bnode.



> As we come across more things that could be reset dynamically, we
> wouldn't have to change the man pages for bos, just refer readers to man
> BosConfig.
>
> Ultimately things like 'bos setrestart' could be subsumed into it, ie, an
> equiv command would be
>
>    bos setparam localhost -param setrestartime -value "16 0 0 0 0"
>
> Similar syntax would apply for checkbintime, etc.

Ugh.  No, we don't need a "bos put this text in the BosConfig file" 
command.  The BosConfig file is not intended to be edited by hand, and its 
format is an implementation detail.  That ugliness really doesn't need to 
be exposed to the user any more than it already is.

>    [ -temp | -perm ]
>
> where -perm causes the BosConfig file to be rewritten immediately and
> -temp means it is left alone. I'm in favor of anything that puts specific
> capabilities back into the hands of the admin.

For a new command you'd need that, or separate commands.  Offhand I can't 
think of any existing commands that need it.  Today, the only change you 
can make to a bnode after creating it is to start and stop it, and we do 
have separate commands for temporary vs permanent changes in state.

-- Jeff