NUTUPSDRV(8)

📦
version 2.8.5 · 18 versions
, in fedora 43, fedora 44

💖 NUTUPSDRV(8) — the NUT Manual, bestie edition 💖

okay so you opened the manual for nutupsdrv and it's lowkey a fake driver?? like it's not a real driver at all, it's the group chat that all the other drivers live in. anyway, let's get into it 🫶

✨ NAME ✨

nutupsdrv — the generic manual for all the unified NUT drivers, fr fr. (This is the combined page for the shared code that's the beating heart of a whole bunch of drivers in the Network UPS Tools package, so like, it's iconic but also it's a manual page for a vibe.)

✨ SYNOPSIS ✨

nutupsdrv -h

nutupsdrv [OPTIONS]

✨ DESCRIPTION ✨

so, plot twist: nutupsdrv is not actually a driver. it's the combined man page for the shared code that is the core of many drivers within the Network UPS Tools package. main character energy, but in a shared library way 💅

if you want the tea on any specific driver, go read its own individual man page. this one is the group chat, not the DM.

UPS drivers provide a communication channel between the physical UPS hardware and the upsd(8) server. The driver is responsible for translating the native protocol of the UPS to the common format used by the rest of this package. basically: the driver speaks UPS, upsd speaks NUT, and the driver is the bilingual bestie doing the translating 🌈

The core has three modes of operation which are determined by the command line switches:

  1. In the normal mode, the driver will periodically poll the UPS for its state and parameters, as per the pollinterval parameter in ups.conf(5). The results of this command are presented to upsd. The driver will also handle setting variables and instant commands if available. (the everyday slay ✨)
  2. In the second mode, using -k, the driver can instruct the UPS to shut down the load, possibly after some delay. This mode of operation is intended for cases when it is known that the UPS is running out of battery power and the systems attached must be turned off to ensure a proper reboot when power returns. (the dramatic exit 💀)
  3. In the third mode, using -d, the driver will exit after some update loops, dumping the data tree (in upsc(8)-like format) to stdout. This can be useful to complement the nut-scanner(8) to discover devices, along with in-depth data. (the gossip dump 🔍)
Note 🙈 You probably don't want to use any of these options directly. You should use upsdrvctl(8) (or upsdrvsvcctl(8) on systems with a service management framework like systemd or SMF) to control your drivers, and ups.conf(5) to configure them. The rest of this manual describes options and parameters that generally are not needed by normal users. like, this is the backstage area, not the stage, okay?? 🎀

✨ OPTIONS ✨

  • -h — Display a help message without doing anything else. This will also list possible values for -x in that driver, and other help text that the driver's author may have provided. the "hi bestie, here's everything" option 🫶
  • -a id — Autoconfigure this driver using the id section of ups.conf(5). This argument is mandatory when calling the driver directly. no id, no entry 🚫
  • -s id — Configure this driver only with command line arguments instead of reading ups.conf(5). To be used instead of the -a option when you need to run a driver not present in the driver configuration file. Instead, driver configuration has to be set with -x options directly in the command line. As such a driver instance cannot be controlled by upsdrvctl(8) or upsdrvsvcctl(8), this option should be used for specific needs only. like, this is the "I'm built different" option 😤
  • -D — Raise the debugging level. Use this multiple times to see more details. Running a driver in debug mode will (by default) prevent it from backgrounding after startup. It will keep on logging information to the console until it receives a SIGINT (usually Ctrl+C) or SIGTERM signal. more Ds, more drama 📢

The level of debugging needed depends both on the driver and the problem you're trying to diagnose. Therefore, first explain the problem you have with a driver to a developer/maintainer, before sending them debugging output. More often than not, if you just pick a level, the output may be either too limited or too verbose to be of any use. do not just dump a wall of text on the maintainers, they will not be obsessed 😭

  • -d update_count — Dump the data tree (in upsc(8)-like format) to stdout after running the driver update loop for the specified update_count times and exit.

By default this prevents the driver process from backgrounding after startup. Note that the driver banner will be printed too, so when using this option in scripts, don't forget to trim the first line, or use the NUT_QUIET_INIT_BANNER environment variable. yes the banner is cute but it will absolutely wreck your parsing ✨

  • -q — Raise log level threshold. Use this multiple times to log more details.

The debugging comment above also applies here. same energy, different flag 💜

  • -c command — Send command to the background process as a signal. Valid commands are:
    • reload — reread configuration files, ignoring modified settings which can not be applied "on the fly"
    • reload-or-error — reread configuration files, ignoring but counting changed values which require a driver restart (can not be changed on the fly), and return a success/fail code based on that count, so the caller can decide the fate of the currently running driver instance
    • reload-or-exit — reread configuration files, exiting the old driver process if it encounters modified settings which can not be applied "on the fly" (so caller like systemd can launch another copy of the driver)
    • exit — tell the currently running driver instance to just exit (so an external caller like the new driver instance, or the systemd or SMF frameworks would start another copy)

With recent NUT v2.8.x releases, such commands can be sent using the Unix socket for driver-server interaction. As a fallback, like older releases, signals can be sent to the PID of an older driver instance (where possible). old school or new school, both ate 🔥

  • -P pid — Send the command signal above using specified PID number, rather than consulting the PID file. This can help define service units which start each NUT driver as a foreground process so it does not create a PID file. See also -FF option as an alternative. for the no-PID-file girlies 🎀
  • -F — Enforce running the driver as a foreground process, regardless of debugging or data-dumping settings. Specify twice (-FF or -F -F) to save the PID file even in this mode. front and center, no backgrounding 💅
  • -B — Enforce running the driver as a background process, regardless of debugging or data-dumping settings. the opposite of the above, we love a balanced queen 👑
  • -i interval — Set the poll interval for the device. The default value is 2 (in seconds). every 2 seconds, she checks in 💖
  • -V — Print only version information, then exit. the "who am I" option ⭐
  • -L — Print a parsable list of driver variables. Mostly useful for configuration wizard programs. wizard-coded 🧙
  • -k — ("Kill" power) Forced shutdown mode. The UPS will power off the attached load, if possible.

You should use upsdrvctl shutdown whenever possible instead of calling this directly. Note that the constrained operating system context for shutdown typically rules out use of upsdrvsvcctl shutdown. this is a real one, bestie — go through upsdrvctl 🙏

  • -r directory — The driver will chroot(2) to directory during initialization. This can be useful when securing systems.

In addition to the state path, many systems will require /dev/null to exist within directory for this to work. The serial ports are opened before the chroot call, so you do not need to create them inside the jail. In fact, it is somewhat safer if you do not (but reconnection to devices may be no longer possible and could require a full restart of the driver). cozy little jail, but make sure /dev/null is in there first 🔒

  • -u username — Override the unprivileged username that the driver may use after startup. If started as root, after opening configuration files (and optionally calling chroot(2), as described in the previous option), the driver will look up username in the passwd database, then change to the user and group identities associated with username. (If started with a nonzero UID or effective UID, the driver will silently ignore this option.) 🤫

When compiling NUT from source, the default username is typically nobody, and this may cause permission errors when the driver opens the UPS device node. You can use this option to temporarily override the defaults. For testing purposes, you can set this option to root to bypass permission errors, especially with USB-based drivers. However, you will want to remove this option later in order to avoid permission conflicts between the driver and the unprivileged copy of upsd(8). temporary fix, permanent consequences, you know how it goes 😭

  • -g groupname — Override the unprivileged group name that the driver may use after startup to set permissions for the filesystem socket so upsd may still access it if the run-time user of the driver normally would deny that access. group chat permissions, basically 🫶
  • -x var=val — Define a variable called var with the value of var in the driver. This varies from driver to driver — see their specific man pages for more information.

This is like setting var=val in ups.conf(5), but -x on command line overrides any settings from that file. command line wins, always 💅

Note that for fallback values of NUT variables poorly supported by a specific device and/or its NUT driver, you can specify default.var.name=val to set a default value (may be replaced at run-time by a reading from the device, if one does arrive), or override.var.name=val to hard-code a value and ignore its readings from the device even if they are served. For example, this is often used with override.battery.voltage.nominal when the device reports a single cell in 2V range, and you are interested in a standard battery package in 12V range, for PbAc. the default. vs override. distinction is the whole game, iykyk 🔥

✨ DIAGNOSTICS ✨

Information about the startup process is printed to stdout and/or stderr. Additional messages after that point are only available in the syslog, unless the driver remains in foreground (e.g. due to raised debugging verbosity). so like, if you want the lore after startup, either check syslog or keep her in the foreground 📝

After upsd(8) starts, the UPS clients such as upsc(8) can be used to query the status of an UPS. that's the "how's she doing" check 🌸

✨ PROGRAM CONTROL ✨

You should always use upsdrvctl(8) (or upsdrvsvcctl(8) on systems with a service management framework like systemd or SMF) to control the drivers. While drivers can be started by hand for testing purposes, it is not recommended for production use. hands off the driver directly, bestie, let upsdrvctl drive 🚗

✨ FILES ✨

  • ups.conf — Required configuration file. This contains all details on which drivers to start and where the hardware is attached. the blueprint, the master doc, the source of truth 💖

🌈 ENVIRONMENT VARIABLES 🌈

okay so these are the vibes your shell hands down to the daemon, and they lowkey control where stuff lives and how chatty it is 💅

  • NUT_DEBUG_LEVEL — sets the default debug verbosity when nobody passed any -D arguments on the command line. Important tho: it does not request that the daemon runs in foreground mode, so don't come crying to me when it still forks off into the background, bestie 😭
  • NUT_CONFPATH — the path name of the directory holding ups.conf and all the other config files. If this variable isn't set, drivers just use a built-in default, which is often /usr/local/ups/etc.
  • NUT_STATEPATH — the path name of the directory where upsd and the drivers keep their shared state information. Not set? Then upsd and drivers fall back to a built-in default, which is often /var/state/ups. oh and psst — the STATEPATH directive in upsd.conf(5) overrides this variable, so that one wins 👑
  • NUT_ALTPIDPATH — the path name of the directory where upsd and the drivers store their .pid files. If it's not set, upsd and the drivers use either NUT_STATEPATH if that's set, or ALTPIDPATH if that's set, or otherwise the built-in default STATEPATH. yes it's a whole chain, we love a priority order 💖
  • NUT_QUIET_INIT_UPSNOTIFY=true — this one stops daemons that can notify service management frameworks (think systemd) about passing their lifecycle milestones from actually emitting those notifications. that includes the ones about the lack of system support for such modern features, which fire once per run. so like, silence, but make it intentional 🤫
  • NUT_QUIET_INIT_BANNER=true — suppresses the NUT tool name and version banner. NOT recommended for services, because it makes troubleshooting way harder (adverse troubleshooting impact, fr fr), but it may be helpful in shell profiles or scripts that process NUT tool outputs. iykyk ✨

💀 BUGS 💀

Some of the drivers may have bugs. See their manuals for more information.

(yeah that's it. that's the whole section. iconic honestly — the manpage is just like "some of them are broken, go read the other manpage" 🙈 no cap, go read the other manual if your driver is acting up.)

🔍 SEE ALSO 🫶

🛠️ Configuration

🖥️ Server

📱 Clients

🌐 CGI programs

🎛️ Driver control

🔌 Drivers

the whole squad, alphabetical, no skips, no cap — literally every single one:

🌍 Internet resources

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

and that's a wrap bestie!! 🎀 this whole thing is from Network UPS Tools 2.8.5, dated 10/07/2026 — go touch some grass now, or better yet, go read the manpage for your actual driver 💜🦋⭐

📦 where this page comes from