Just launch nut-server systemd service if we are not on netclient mode

[Marzal]

Tested with ExecCondition=/bin/sh -c '[ "$MODE" != "netclient" ]'

This is more than a RFC than an intent to have the PR merged.

nut.target tries to start nut-driver.target nut-server.service nut-monitor.service.
On distros like Arch where nut is packaged as only one package, configured as netclient system, nut-server.service fails with Fatal error: at least one UPS must be defined in ups.conf.

Tried to just enable nut-monitor.service but seems not to work without nut.target enabled. 1

If upsd could detect the MODE=netclient and exits without failing could be another solution.

So my questions is: if making nut-server.service only start if we are not on MODE=netclient is something that upstream could consider? , or if I should ask this on Arch itself?

Thanks for this great software!

[jimklimov]

This looks like a neat idea in fact, may help fix the long-standing issue #837 and loosely related to the likes of #156 (and others referred from these two).

Did you check if this actually works, e.g. things are not getting broken by various values of MODE in nut.conf, or the lack of such file?

Other than that, your original issue can be addressed by ALLOW_NO_DEVICE setting in upsd.conf.

[Marzal]

Thanks I didn't find those issues.

This it's what I have tested with /etc/nut/nut.conf:

• #MODE=* (commented) -> $MODE not set -> service execute and fails without one UPS defined . [MODE=none is the default]. Same behavior than before the change.
• Same for /etc/nut/nut.conf not existing.
• MODE=none -> $MODE it's different to netclient -> service execute and fails. Same behavior than before the change.
• MODE=netclient -> $MODE it's equal to netclient -> nut-server.service: Skipped due to 'exec-condition'. Improvement

I could complicate the test with something like
[ "$MODE" != "netclient" -o "$MODE" != "none" ] or [ "$MODE" = "standalone" -o "$MODE" = "netserver" ]
But I don't know if it is expected to enable nut.target if you leave MODE=none. If not "$MODE" != "netclient" it's enough to improve that case with no drawbacks that I'm aware.

Happy to do more testing if anyone has something in mind.

[jimklimov]

I think the linked older issues suggested that (packaged) services are supposed to be pre-set to try starting automatically, and decide at run-time if they would run.

Regarding your practical tests, failures due to lack of UPS config (and no ALLOW_NO_DEVICES in effect) may be more holistically solved by adding some nutprogname -c testconf (as many other programs do - DNS, mail, web servers), so the daemon/tool would evaluate if it is sufficiently configured to currently start. NUT programs themselves do not care about MODE, but checking that the rest of configs preclude or allow start-up can be done as the program's activity. This PR showed that ExecCondition is a decent vessel for that, thanks :)

Per https://www.freedesktop.org/software/systemd/man/systemd.unit.html the ExecCondition was "Added in version 243", so for the benefit of NUT builds on older distros (to power-protect older boxes) we might want to check for it in configure.ac like we do for a number of other keywords.

[Marzal]

Hi, I'm glad this could help previous discussions (I have now read the other issues and I see this was a discussed topic).

I like the ExecCondition option over ALLOW_NO_DEVICE=true because I would rather not run nut-server.service on a system that is never going to use it.

I tried to look at https://github.com/networkupstools/nut/blob/master/configure.ac but it's too much for my dev skills (I'm a sysadmin).

According to https://pkgs.org/download/systemd and https://repology.org/project/systemd/versions there are only 2 main distros with systemd < 243.

Enterprise Linux 8 (RHEL, Rocky Linux, AlmaLinux)

• systemd 239
• nut-2.8.2-1.el8.x86_64.rpm

And AmazonLinux 2 (EOL on 2026-06-30)

• systemd 219
• no nut package
• Amazon Linux 2023 the successor o AL2 has systemd 252

So, it is going to be any old distro with systemd < 243 and a updated version of nut > 2.8.4 ? I use Arch, debian and Ubuntu, so I'm probably not aware of the whole ecosystem of nut distros.

PD: Just integrated today nut to Home Assistant. Very cool.

[jimklimov]

FWIW, ALLOW_NO_DEVICE=true appeared for dynamic management systems and apliances, where you want to know a NUT server is running and deliberately knows of no devices at the moment, rather than it being not accessible and vague.

[Marzal]

FWIW, ALLOW_NO_DEVICE=true appeared for dynamic management systems and apliances, where you want to know a NUT server is running and deliberately knows of no devices at the moment, rather than it being not accessible and vague.

Yeah, for that use case makes sense.

[jimklimov]

PR updated, tested locally with MODE=netserver (so not expecting local client daemons), and upsmon indeed refused to start now:

* nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
     Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/nut-monitor.service.d
             └─debug.conf
     Active: inactive (dead) (Result: exec-condition) since Fri 2026-01-02 12:32:41 CET; 44s ago
 Invocation: 2cc2b9f97b474506859f732d975052b6
  Condition: start condition unmet at Fri 2026-01-02 12:32:41 CET; 44s ago
       Docs: man:upsmon(8)
             https://www.networkupstools.org/docs/man/upsmon.html
             man:upsmon.conf(5)
             https://www.networkupstools.org/docs/man/upsmon.conf.html
             man:nut.conf(5)
             https://www.networkupstools.org/docs/man/nut.conf.html
    Process: 460887 ExecCondition=/bin/sh -c [ x"${MODE}" != x"netserver" ] (code=exited, status=1/FAILURE)
   Mem peak: 2M
        CPU: 3ms

Jan 02 12:32:41 pve systemd[1]: Starting nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller...
Jan 02 12:32:41 pve systemd[1]: nut-monitor.service: Skipped due to 'exec-condition'.
Jan 02 12:32:41 pve systemd[1]: Condition check resulted in nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller being skipped.

The unit is "dead" because ExecCondition ended with status=1/FAILURE, but it not listed among systemctl status --failed as its current state is not an unexpected failure.

[Marzal]

Wow, great work. Full support of ExecCondition for the different use cases 🥳

[jimklimov]

Hm, actually netserver is documented as Like the standalone configuration, but also possibly need one or more specific LISTEN directive(s) in upsd.conf, so it is a full setup with not only localhost clients possible. So limiting nut-monitor.service like this was overkill :)

Meant to experiment with none there and overshot.