-
-
Notifications
You must be signed in to change notification settings - Fork 359
NUT systemd service units
As originally detailed for https://github.com/networkupstools/nut/issues/2721#issuecomment-2545360867 NUT since v2.8.0 significantly revised the nut-driver
start-up on systemd-enabled operating systems, thanks to nut-driver-enumerator (NDE) handling individual driver wrappings.
Some distributions, manual installations e.g. when Building NUT for in‐place upgrades or non‐disruptive tests, and/or end-user craftiness can leave some important units disabled from auto-start. You can see site-local configuration under your /etc/systemd/system/
directory (there are more locations for packaged /usr/lib/systemd
, core /lib/systemd/
, or run-time /run/systemd/
which are not of interest at the moment).
Since PR #2746 (to be released in NUT v2.8.3) you can also sudo systemctl preset-all
but beware -- this instills an opinionated selection of enabled and disabled units, so can override whatever you have customized locally. See the nut-systemd.preset
file for more details. That PR also adds nut-logger
(wrapping of upslog
daemon as a service, disabled by default).
Generally note that in systemd:
- the
unitname.d
directories allow "drop-in" customizations over the default unit as delivered by packaging and/or allowing instantiation (e.g.[email protected]
definition); - links to
/dev/null
mark masked services that should never get enabled or started; - enablement of targets (and other units) for auto-start should have been part of packaging, or can be done manually as
systemctl enable UNITNAME
.
Overall, a mesh of systemd units can look like the following:
:; ls -ld `find /etc/systemd | grep -w nut | sort
lrwxrwxrwx 1 root root 30 Dec 5 03:32 /etc/systemd/system/multi-user.target.wants/nut.target -> /lib/systemd/system/nut.target
drwxr-xr-x 2 root root 4 Apr 19 2024 /etc/systemd/system/nut-driver.target.wants
lrwxrwxrwx 1 root root 39 Jan 2 2023 /etc/systemd/system/nut-driver.target.wants/[email protected] -> /lib/systemd/system/[email protected]
lrwxrwxrwx 1 root root 39 Apr 19 2024 /etc/systemd/system/nut-driver.target.wants/[email protected] -> /lib/systemd/system/[email protected]
drwxr-xr-x 2 root root 3 Nov 1 2022 /etc/systemd/system/[email protected]
-rw-r--r-- 1 root root 81 Apr 19 2023 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
lrwxrwxrwx 1 root root 9 Jan 2 2023 /etc/systemd/system/[email protected] -> /dev/null
drwxr-xr-x 2 root root 4 Apr 19 2024 /etc/systemd/system/[email protected]
-rw-r--r-- 1 root root 74 Jul 23 00:47 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
-rw-r--r-- 1 root root 39 Apr 19 2024 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated-devicename.conf
drwxr-xr-x 2 root root 5 Apr 19 2024 /etc/systemd/system/[email protected]
-rw-r--r-- 1 root root 74 Apr 19 2024 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
-rw-r--r-- 1 root root 40 Apr 19 2024 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated-devicename.conf
-rw-r--r-- 1 root root 364 Apr 19 2024 /etc/systemd/system/[email protected]/nut-driver-enumerator-generated.conf
drwxr-xr-x 2 root root 7 Dec 5 03:32 /etc/systemd/system/nut.target.wants
lrwxrwxrwx 1 root root 46 Dec 5 03:32 /etc/systemd/system/nut.target.wants/nut-driver-enumerator.path -> /lib/systemd/system/nut-driver-enumerator.path
lrwxrwxrwx 1 root root 49 Dec 5 03:32 /etc/systemd/system/nut.target.wants/nut-driver-enumerator.service -> /lib/systemd/system/nut-driver-enumerator.service
lrwxrwxrwx 1 root root 37 Dec 5 03:32 /etc/systemd/system/nut.target.wants/nut-driver.target -> /lib/systemd/system/nut-driver.target
lrwxrwxrwx 1 root root 39 Dec 5 03:32 /etc/systemd/system/nut.target.wants/nut-monitor.service -> /lib/systemd/system/nut-monitor.service
lrwxrwxrwx 1 root root 38 Dec 5 03:32 /etc/systemd/system/nut.target.wants/nut-server.service -> /lib/systemd/system/nut-server.service
Detailing the lines as they go:
- Result of
systemctl enable nut.target
, so the system milestonemulti-user.target
"wants" (tries, does not fail if unsuccessful) to start NUT (whatevernut.target
would pull in):
/etc/systemd/system/multi-user.target.wants/nut.target -> /lib/systemd/system/nut.target
- Result of
systemctl enable nut-driver@{dummy,eco650}.service
, done by NDE based onups.conf
contents:
/etc/systemd/system/nut-driver.target.wants
/etc/systemd/system/nut-driver.target.wants/[email protected] -> /lib/systemd/system/[email protected]
/etc/systemd/system/nut-driver.target.wants/[email protected] -> /lib/systemd/system/[email protected]
- Nominal customization of
[email protected]
template, generated by NDE fromups.conf
contents for tracking of "global" part of configuration:
/etc/systemd/system/[email protected]
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
- The
[email protected]
never auto-starts; I can manage that (virtual) NUT driver as a program in testing whichever way I like (e.g. with command-line configuration):
/etc/systemd/system/[email protected] -> /dev/null
- Customizations for unit of a
dummy
UPS, generated by NDE fromups.conf
contents:
/etc/systemd/system/[email protected]
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated-devicename.conf
- Customizations for unit of a for
eco650
UPS, generated by NDE fromups.conf
contents:
/etc/systemd/system/[email protected]
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated-checksum.conf
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated-devicename.conf
/etc/systemd/system/[email protected]/nut-driver-enumerator-generated.conf
- Result of
systemctl enable nut-driver-enumerator.{path,service} nut-driver.target nut-monitor.service nut-server.service
which "wants" those units to auto-start as part ofnut.target
which in turn would be "wanted" by the system milestonemulti-user.target
as seen above (note there are other NUT units, especially around NDE implementation variants, that may be or not be useful in a particular deployment):
/etc/systemd/system/nut.target.wants
/etc/systemd/system/nut.target.wants/nut-driver-enumerator.path -> /lib/systemd/system/nut-driver-enumerator.path
/etc/systemd/system/nut.target.wants/nut-driver-enumerator.service -> /lib/systemd/system/nut-driver-enumerator.service
/etc/systemd/system/nut.target.wants/nut-driver.target -> /lib/systemd/system/nut-driver.target
/etc/systemd/system/nut.target.wants/nut-monitor.service -> /lib/systemd/system/nut-monitor.service
/etc/systemd/system/nut.target.wants/nut-server.service -> /lib/systemd/system/nut-server.service
Welcome to the Network UPS Tools (NUT) project Wiki, and feel free to contribute tricks and insights.
While there are several good entries in the menu, ones referenced most frequently in issue discussions include:
- Building NUT for in-place upgrades or non-disruptive tests and Using NIT (NUT Integration Test suite) sandbox
- Technicalities: Customizing (NUT) config files and scripts delivered by packaging
- Links to distribution packaging recipes and repository sections
- Troubleshooting
upsdrvctl
drivers not starting ("insufficient permissions on everything" or "Can't claim USB device [VVVV:PPPP]@0/0: Entity not found") possibly due to nut-driver-enumerator (NDE) services having been there before you with NUT 2.8.x, and "insufficient permissions" when starting USB drivers for a different PoV on this; see also an example unit deployment detailed in NUT systemd service units page - Changing NUT daemon debug verbosity
- Building NUT integration for Home Assistant
- Running NUT in an LXC container
- Troubleshooting eventual disconnections (Data stale) and CyberPower Systems (CPS) know-how
- NUT for Windows
- NUT HCL and DDL
- Code contributions, PRs, PGP and DCO
- NUT CI farm
Also keep in mind the documentation links from NUT website and the FAQ in particular.