On Sat, Sep 12, 2009 at 11:12 AM, Toni Mueller<openbsd-m...@oeko.net> wrote:
> Hi,
>
> On Fri, 11.09.2009 at 22:28:43 +0200, Maurice Janssen <maur...@z74.net> wrote:
>> Will the master shutdown normally, or will it stall while trying to
>> umount the NFS share?  The slaves will shutdown first, so when the
>> master goes down, the NFS server won't be responding.
>
> man mount_nfs
>
> You can mount NFS shares soft. This means that it becomes less reliable
> for you, but your clients won't hang if you shut down your NFS server
> first.
>
> Another option could be to somehow notify your NFS clients, so they
> know that they need to unmount the NFS shares.


To expand on what Toni and Mauro have said, see "man shutdown", the -k option:
k as in "kick everybody off".  Since at some point each machine will kick
everyone off, that point might as well be now, and we might as well
control the order in which it happens.

Presumably the NFS file systems are not something critical to root,
and can  then be umounted by a script.  If there are files needed, I
suggest preparing a shadow
tree over which the NFS fs's are mounted.   Once users have been kicked
off, the nfs server can be shutdown.  Now in general there will be NFS
fs's mounted on third machines, and those should be shut down in the same
fashion, before the NFS server.  This sequence would be the same regardless
of the reason for shutting down the LAN.

Briefly, then:
           1) UPS software ("nut" I guess) tells "master", "power failing soon".
           2) "Master" tells all slaves except "server", "shutdown
<nice delay> Powerfailure"
           3) "Master" tells itself "shutdown -k <nice delay>"
           4) "Master" umounts "all".
           5) "Master" tells "nfs server": "shutdown now"
           6) "Master" completes its own shutdown.

"tells" in this scheme might be through "nut", or more simply, ssh.  I
don't know
about "nut".

And of course, somewhere around step 5, the power comes back on ;-)

Dave

Reply via email to