Arjen de Korte wrote: > Citeren Thomas Gutzler <[email protected]>: > >> So when the batteries are critical, the master >> - sends out FSD to all slaves and touches POWERDOWNFLAG >> - waits for slaves to disconnect or max HOSTSYNC seconds to pass >> - waits another FINALDELAY seconds >> - executes its SHUTDOWNCMD, which >> - stops upsd, the drivers and the master upsmon (K50nut) >> - stops the nfs server (K80nfs-kernel-server) >> - runs upsdrvctl shutdown (S90halt) to shut down the UPSes >> >> When a slave detects a FSD, it >> - processes NOTIFY_SHUTDOWN (send an email in my case) >> - waits for FINALDELAY seconds >> - executes its SHUTDOWNCMD instantly, which >> - unmounts all nfs drives (S31umountnfs.sh) >> - causes upsmon to disconnect and stop (K50nut) and >> - shortly after powers off the system (as long as it takes to execute >> the remaining few shutdown scripts) >> >> If that's correct, isn't it better to set FINALDELAY to 0 and increase >> HOSTSYNC for all slaves rather than increasing FINALDELAY for the >> master? Shouldn't HOSTSYNC be the time the slowest slave needs to get to >> the nut shutdown script after receiving a shutdown, which can be delayed >> by up to POLLFREQALERT seconds? > > The above may work, provided the kill script for NUT isn't run before > the NFS drives have unmounted. In your setup, this may be true, but this > may not be so in the general case. Also, the behavior of NUT clients > when they see the FSD flag is explicitly not defined. They may logout > from the server immediately and start shutting down only after that. A > 'FINALDELAY 120' on the NFS system guarantee at *least* 120 seconds for > the clients to unmount their NFS drives from the moment the FSD flag is > set. Using 'HOSTSYNC 120' guarantees at *most* 120 seconds (but it could > be lower as well), so we don't recommend that.
Alright, given the uncertainty, I shall follow your recommendation and set FINALDELAY to 120 on my master and 5 on the slaves and leave the HOSTSYNC untouched. Once I've done my first test I will know whether those numbers are suitable or not. > You can't use POLLFREQALERT to delay the shutdown. I didn't mean to. I only mentioned it because it *can* cause another delay of up to POLLFREQALERT in the shutdown process, which would have mattered slightly in my above calculation. Although I did set it to 5 so the delay would have been negligible. Thanks again for your patience and assistance! Cheers, Tom _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
