Modern operating systems offer service management frameworks, like the Solaris 10/11 and illumos SMF, or Linux systemd. These frameworks drive the life cycle of the operating system and enforce their opinions on the shutdown end-game in particular. For example, any "user-land" processes which remain alive after a certain (configurable or hard-coded) timeout would be killed off to not block the shutdown or reboot request.

While systemd has a concept of shutdown hooks, so the logic above can be placed as a script into a special directory /usr/lib/systemd/system-shutdown and called after all the service daemons have been killed off, the SMF does not commonly offer such a facility.

Instead, the question is turned around: "What would break in your system if it is suddenly turned off (not only due to power, but also kernel panic, hardware failure, etc.?)" and the suggested solutions follow up from there.

The copy-on-write filesystems, like ZFS extensively used in Solaris/illumos as well as other operating systems (including some *BSD and Linux distributions), do not care about sudden reboots (assuming the storage hardware does not lie about honouring orderly metadata flushes). At worst, an incomplete transaction would be lost, but the filesystem structure itself remains valid and does not need any lengthy fsck after a reboot.

It may be or not be similar with databases (depending on how yours would log incoming write transactions), mail systems, etc.

Chances are, with a complete stack of well-engineered software for which hardware failure is always an option (considered in design), you do not even need to shut down anything in case of reported power failure and the UPS going on battery.

In practice, if you are not after maximizing the service uptime but rather want some peace of mind that your application data is not corrupted, you can script your NOTIFYCMD implementation to stop just those services (containers, VMs…), maybe umount non-transactional file systems (FAT EFI partition, USB storage), and revive them when/if the UPS becomes "on-line" again and this box is still alive. Or it just boots up if the power did get lost (whether you requested the UPS to power-off or power-cycle or not, whether it honoured such request or not). Probably upssched as the notification handler can help implement this logic consistently, so it would react to different events. Using service grouping or milestones as a way to consistently start/stop "fragile" services should also help (in this case the framework ensures the action only happens once, regardless of how many times your scripts requested it).

Notably, with this approach you DO NOT tell the OS to actually shut down, and so suffer any forced kill of user-land processes after any timeouts. You choose which services might be hurt by the outage and should go down, and which can run as long as they can (or in which mode, e.g. turning your mail, DNS or LDAP server read-only just in case until the storm passes). The still-running stub of your OS is the environment which talks to the UPS and takes care of eventually restarting the services or the whole box, as you deem fit.