0
0
Fork 0
mirror of https://github.com/networkupstools/nut.git synced 2026-04-21 06:21:22 +00:00
3 NUT systemd service units
Jim Klimov edited this page 2026-01-15 08:54:50 +01:00
This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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 inplace upgrades or nondisruptive 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. nut-driver@.service 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/nut-driver@dummy.service -> /lib/systemd/system/nut-driver@.service
lrwxrwxrwx 1 root root  39 Apr 19  2024 /etc/systemd/system/nut-driver.target.wants/nut-driver@eco650.service -> /lib/systemd/system/nut-driver@.service
drwxr-xr-x 2 root root   3 Nov  1  2022 /etc/systemd/system/nut-driver@.service.d
-rw-r--r-- 1 root root  81 Apr 19  2023 /etc/systemd/system/nut-driver@.service.d/nut-driver-enumerator-generated-checksum.conf
lrwxrwxrwx 1 root root   9 Jan  2  2023 /etc/systemd/system/nut-driver@dummy.service -> /dev/null
drwxr-xr-x 2 root root   4 Apr 19  2024 /etc/systemd/system/nut-driver@dummy.service.d
-rw-r--r-- 1 root root  74 Jul 23 00:47 /etc/systemd/system/nut-driver@dummy.service.d/nut-driver-enumerator-generated-checksum.conf
-rw-r--r-- 1 root root  39 Apr 19  2024 /etc/systemd/system/nut-driver@dummy.service.d/nut-driver-enumerator-generated-devicename.conf
drwxr-xr-x 2 root root   5 Apr 19  2024 /etc/systemd/system/nut-driver@eco650.service.d
-rw-r--r-- 1 root root  74 Apr 19  2024 /etc/systemd/system/nut-driver@eco650.service.d/nut-driver-enumerator-generated-checksum.conf
-rw-r--r-- 1 root root  40 Apr 19  2024 /etc/systemd/system/nut-driver@eco650.service.d/nut-driver-enumerator-generated-devicename.conf
-rw-r--r-- 1 root root 364 Apr 19  2024 /etc/systemd/system/nut-driver@eco650.service.d/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 milestone multi-user.target "wants" (tries, does not fail if unsuccessful) to start NUT (whatever nut.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 on ups.conf contents:
/etc/systemd/system/nut-driver.target.wants
/etc/systemd/system/nut-driver.target.wants/nut-driver@dummy.service -> /lib/systemd/system/nut-driver@.service
/etc/systemd/system/nut-driver.target.wants/nut-driver@eco650.service -> /lib/systemd/system/nut-driver@.service
  • Nominal customization of nut-driver@.service.d template, generated by NDE from ups.conf contents for tracking of "global" part of configuration:
/etc/systemd/system/nut-driver@.service.d
/etc/systemd/system/nut-driver@.service.d/nut-driver-enumerator-generated-checksum.conf
  • The nut-driver@dummy.service 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/nut-driver@dummy.service -> /dev/null
  • Customizations for unit of a dummy UPS, generated by NDE from ups.conf contents:
/etc/systemd/system/nut-driver@dummy.service.d
/etc/systemd/system/nut-driver@dummy.service.d/nut-driver-enumerator-generated-checksum.conf
/etc/systemd/system/nut-driver@dummy.service.d/nut-driver-enumerator-generated-devicename.conf
  • Customizations for unit of a for eco650 UPS, generated by NDE from ups.conf contents:
/etc/systemd/system/nut-driver@eco650.service.d
/etc/systemd/system/nut-driver@eco650.service.d/nut-driver-enumerator-generated-checksum.conf
/etc/systemd/system/nut-driver@eco650.service.d/nut-driver-enumerator-generated-devicename.conf
/etc/systemd/system/nut-driver@eco650.service.d/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 of nut.target which in turn would be "wanted" by the system milestone multi-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

Also note that systemd drop-in files for site-specific nuances can be created by e.g. ansible recipes that manage a machine, an example of the YAML is posted at https://github.com/networkupstools/nut/issues/1983#issuecomment-3752530376