On Nov 21, 2015, at 2:06 PM, john hart <[email protected]> wrote: > > 1. When communications are lost, instead of shutting down immediately why > not set a flag and then stop the driver and then restart the driver. If > communication is not re-established, and the flag was set, then shut down the > system. Perhaps this is already being done.
This is not likely to be implemented any time soon. It is too dependent on distribution-related things, like how the driver is launched. Our preference is to fix the driver so that it reconnects itself, but the maintainer of the blazer_* drivers has not worked on NUT for several years (hence the move to nutdrv_qx). > 2. In my case, when the shutdown occurs due to loss of communication, the > NUT software tries to turn off the UPS. It can't do that because there is no > communication. This cause the shutdown process to hang up for some period of > time. In my opinion this is not good because the system may crash during > that period when it is hung. The software should skip trying to shut off the > UPS and just execute a normal shutdown. NUT cannot foresee every kind of communication failure, and most of the drivers already have timeouts built in. As a backup, the distribution startup/shutdown scripts should probably have timeouts as well - this used to be implemented as a delay between sending SIGTERM and SIGKILL. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
