Currently when the system shutdown begins, NUT units are among the first ones to stop since their multi-user.target reason-to-be becomes disabled. Sometimes other units (e.g. wrappers of VMs and containers, appserver-db chains, etc.) take much longer to stop and the system is in the dark about current UPS info.
See if dependencies can be reshuffled so that NUT units only finish when all the long shutdown parts have completed and we are just about to actively enter the shutdown/restart/... targets, and that systemd won't terminate them after 90 seconds just for lingering.
Note that currently we re-run the driver(s) on the primary monitoring system to kill power, if configured to, as part of systemd shutdown hooks - that is a separate subject, but the "production" driver must be no longer running by that moment.
CC @bigon @svarshavchik @aquette : any ideas? :)
TODO: Check if similar issue bites in SMF as well.
Currently when the system shutdown begins, NUT units are among the first ones to stop since their
multi-user.targetreason-to-be becomes disabled. Sometimes other units (e.g. wrappers of VMs and containers, appserver-db chains, etc.) take much longer to stop and the system is in the dark about current UPS info.See if dependencies can be reshuffled so that NUT units only finish when all the long shutdown parts have completed and we are just about to actively enter the shutdown/restart/... targets, and that systemd won't terminate them after 90 seconds just for lingering.
Note that currently we re-run the driver(s) on the primary monitoring system to kill power, if configured to, as part of systemd shutdown hooks - that is a separate subject, but the "production" driver must be no longer running by that moment.
CC @bigon @svarshavchik @aquette : any ideas? :)
TODO: Check if similar issue bites in SMF as well.