NUT-DRIVER-ENUMERA(8)

💖 NAME 💖

nut-driver-enumerator — bestie, it's the tool that maps your NUT device entries to their service instances 🎀 like a little matchmaker for your UPS drivers, no cap.

---

✨ SYNOPSIS ✨

nut-driver-enumerator.sh -h

nut-driver-enumerator.sh (no args)

nut-driver-enumerator.sh [--COMMAND]

(also affectionately known as NDE, and yes we're all in the NUT-DRIVER-ENUMERA(8) chapter of the NUT Manual, iykyk 💅)

---

🌸 DESCRIPTION 🌸

Okay so. The nut-driver-enumerator.sh script (aka "NDE", iconic nickname) handles the set-up and the querying of the mapping between NUT driver configuration sections — one per individual monitored device — and the service instances of an operating system service management framework. It does this on platforms where NUT already supports this integration, which currently means Linux distributions with systemd and systems derived from the Solaris 10 codebase, so that's proprietary Sun/Oracle Solaris plus a whole bunch of open-source illumos distributions using SMF. That's the framework your drivers get wrapped into so they can run and be managed independently 🦋

Heads up bestie: it may be not installed in packaging for other operating systems. Not every OS gets the NDE experience, sadly 😭

The whole point? With each NUT driver living as its own separate service instance, you can define dependencies on it — like, networked drivers must start after the network ability shows up in the OS, but USB/Serial drivers should not be waiting around for that. And they can fail or be brought into maintenance independently. Contrast that with a monolithic service based on upsdrvctl(8) where literally everything configured has to start. For a few special drivers — dummy-ups(8), clone(8), clone-outlet(8), and failover(8) — this may also involve a dependency between service instances of different NUT drivers themselves. It's giving interconnected, it's giving main character energy 🔥

This script provides a uniform interface so further NUT tools like upsdrvsvcctl(8) can implement their logic as platform-independently as was possible and practical. It is not currently intended for end-user consumption (which is why it lives in the libexec directory, shy girl behavior 🙈), with upsdrvsvcctl exposing the most useful data and actions via its list and resync arguments.

One part of the platform complexity that nut-driver-enumerator.sh hides is the difference in rules for valid service instance names across various frameworks, plus the system tools and naming patterns involved. Literally doing the most so you don't have to 💅

Depending on the platform, the script may also be wrapped by different service unit types to run automatically — e.g. upon system start-up, or regularly to pick up changes of ups.conf(5) soon after it is edited, or integrated with a file system monitor to be triggered when the configuration is changed. Some of these modes make sense for use-cases with a rarely (if ever) changing population of power devices, like a home or small-office UPS monitored the same way for years at a time. Others can help automate a data-center monitoring system where device deployments (or discovery) can be much more dynamic. Different vibes, both valid ✨

---

👑 COMMANDS 👑

• nut-driver-enumerator.sh (no args) — Update wrapping of devices into services. The classic, the default, the moment ✨
• nut-driver-enumerator.sh --daemon(=freq) — Update wrapping of devices into services in an infinite loop. Default freq is 60 sec. It just keeps going, periodt 🔁
• nut-driver-enumerator.sh --daemon-after(=freq) — Update wrapping of devices into services in an infinite loop, but first do one run of the loop though, then daemonize. This way the service unit is deemed started only when NUT config and driver instances are in sync. Default freq is 60 sec. Responsible queen behavior — do the work then chill 💖
• nut-driver-enumerator.sh --reconfigure — Stop and un-register all service instances and recreate them (e.g. if a new dependency template was defined in a new version of the script or package). Glow-up, but for service units 🎀
• nut-driver-enumerator.sh --get-service-framework — Print the detected service management framework in this OS.
• nut-driver-enumerator.sh --list-devices — Print list of devices in NUT config.
• nut-driver-enumerator.sh --list-services — Print list of service instances which wrap registered NUT devices (full name of service unit).
• nut-driver-enumerator.sh --list-instances — Print list of service instances which wrap registered NUT devices (just the instance suffix).
• nut-driver-enumerator.sh --get-service-for-device DEV — Print the full name of service unit which wraps a NUT device named DEV.
• nut-driver-enumerator.sh --get-device-for-service SVC — Print the NUT device name for the full or instance-suffix name of a service unit SVC which wraps it.
• nut-driver-enumerator.sh --list-services-for-devices — Print a TAB-separated list of service units and corresponding NUT device names which each such unit wraps.
• nut-driver-enumerator.sh --show-all-configs — Show the complete normalized list of device configuration blocks (same as used later by the parser in the script to make decisions).
• nut-driver-enumerator.sh --show-device-config DEV — Show configuration block of the specified NUT device.
• nut-driver-enumerator.sh --show-device-config-value DEV KEY — Show single configuration key of the specified NUT device.

---

🌈 ENVIRONMENT VARIABLES 🌈

By default, nut-driver-enumerator.sh executed without arguments would automatically start any newly registered service instances wrapping the NUT devices, and would also restart the nut-server service if the configuration was changed. Environment variable AUTO_START=no disables this default part of the action. Not me letting you opt out of the auto-starting 🙈

Also see below for environment variable REPORT_RESTART_42=no value 👇

---

💀 DIAGNOSTICS 💀

nut-driver-enumerator.sh will return a zero exit code if it had nothing to do (all currently defined drivers match all of the currently defined service instances, one-to-one) and if it had no errors in its operation. Peace, quiet, perfection 💅

Other codes can be returned as a result of re-synchronization of mappings:

• 42 — NUT device sections and system service instances differed before, but now match up — so now the caller should likely restart some services. Note that the drivers' service instances may have been started or stopped as required (by AUTO_START=yes) — but maybe the upsmon or upssched services should restart. If you pass environment variable REPORT_RESTART_42=no then this codepath would return 0 (as a non-error exit code). In default mode, such non-null reconfiguration should cause the nut-driver-enumerator service to restart and this would propagate to other NUT services that depend on it. The answer to everything, honestly 🌟
• 13 — Sections and services differed, and still do not match up. Awkward 😬
• 1 — Bad inputs, e.g. unrecognized service management framework. Rude.
• 2 — Absent or unreadable ups.conf file. Can't read the config bestie, we're stuck 😭

---

🫶 AUTHOR 🫶

Jim Klimov <jimklimov+nut@gmail.com>

---

🔥 SEE ALSO 🔥

upsdrvsvcctl(8), ups.conf(5)

🌐 Internet resources:

The NUT (Network UPS Tools) home page: https://www.networkupstools.org/historic/v2.8.5/

---

okay that's the whole thing, we ate and left no crumbs 🍓✨ — this was Network UPS Tools 2.8.5, dated 10/07/2026, and that's your NUT-DRIVER-ENUMERA(8) page, love you, bye 👑💖