Problem/Justification
TrueNAS does not provide a persistent way to configure the NUT FINALDELAY parameter for upsmon. Any manual changes to /etc/nut/upsmon.conf are overwritten whenever the UPS service restarts or the configuration is regenerated.
This has been requested multiple times before but is still unresolved:
There is also a related request to expose upsmon.conf auxiliary parameters in the UI, which was declined due to maintainability concerns:
A commonly suggested workaround is using pre-init scripts to re-inject FINALDELAY (Like mentioned in one of the articles before). While this can work initially, it is not reliable in practice: any UPS service restart, UI change, or configuration regeneration will remove the value again.
TrueNAS already offers a “Shutdown Timer” (UPS on-battery delay), but this is static and only applies at the moment the system switches to battery. It does not adapt to changing conditions like low-battery events.
In practice, this leaves no way to dynamically adjust the final shutdown phase based on remaining UPS runtime.
This becomes a real issue in setups where multiple client systems depend on the TrueNAS. These systems often take several minutes to shut down properly. HOSTSYNC is not sufficient here, as it only ensures clients start shutdown after FSD, not that they finish it.
There is currently no supported way to ensure TrueNAS stays online long enough for all dependent systems to fully complete shutdown before it powers off, or at least provide enough time for the clients to properly shutdown.
FINALDELAY is exactly meant for this last phase: a controlled delay between shutdown notification and the final shutdown command. Without it, the shutdown window for clients can be too short, increasing the risk of incomplete shutdowns.
Impact
Adding persistent support for FINALDELAY would improve shutdown reliability in multi-system environments.
Benefits:
- More predictable shutdown order in NUT setups
- Ensures clients have enough time to fully shut down
- Reduces race conditions during power loss
- Improves data safety in dependent infrastructures
- Removes the need for brittle pre-init workarounds
Trade-offs:
- Slight increase in configuration complexity
- Requires understanding of HOSTSYNC vs FINALDELAY => Explanation in the “?” Box?
User Story
An administrator runs TrueNAS as a NUT UPS master in an environment with multiple dependent systems (for example virtualization hosts). For my example, I do run a small homelab with a TrueNAS Scale and Proxmox Nodes. Those Proxmox Nodes (including some VMs) rely on the TrueNAS to be available during shutdown.
During a power outage:
- The UPS enters battery mode
- As runtime decreases, the UPS transitions into a critical state requiring immediate shutdown action.
- TrueNAS initiates a forced shutdown sequence and notifies all connected clients.
- The clients require several minutes to complete safe shutdown operations, including stopping virtual machines.
- These clients continue to rely on TrueNAS during parts of their shutdown process.
- The administrator needs TrueNAS to remain online long enough after issuing shutdown notifications to ensure all dependent systems have fully completed shutdown.
- A persistent FINALDELAY value allows TrueNAS to apply a final, dynamic buffer before executing its own shutdown, ensuring it is always the last system in the shutdown chain.
This ensures a deterministic shutdown order, improves data safety, and provides a more reliable recovery state after power restoration.
Administrators would still need to size the timing correctly, but this option would at least provide the necessary control to design and implement a predictable and safe shutdown schedule.