Just launch nut-server systemd servide 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]

@SBINDIR@ is for NUT's system binaries; this is not necessarily where OS binaries co-exist.
I think Unix standards dictate that a /sbin/sh (for system scripts) exists, may be or not be same as /bin/sh (default for interactive users) - so please rather refer to one of those.

[Marzal]

You are right, I've check
debian:
bin -> usr/bin
sbin -> usr/sbin
/usr/sbin/upsd
/usr/bin/sh

Arch:
bin -> usr/bin/
sbin -> usr/bin/
/usr/bin/upsd
/usr/bin/sh

So it's the same PATH on Arch but not debian. It's in /bin/sh / /usr/bin/sh on both cases.

[Marzal]

Searching the use of ExecCondition with sh, a few more examples use /bin/sh like

• https://stackoverflow.com/questions/76055699/how-can-i-negate-the-exit-code-of-a-command-used-in-execcondition-of-a-systemd-s
• https://devsolus.com/how-can-i-negate-the-exit-code-of-a-command-used-in-execcondition-of-a-systemd-service/
• https://ro.qask.org/server/2022/11/05/systemd-valoare-l-necunoscuta-execcondition-in-sectiunea-service
• https://serverfault.com/questions/1068680/systemd-unknown-lvalue-execcondition-in-section-service
• Feature request: Option to suppress normal output jqlang/jq#1225

And others just sh

• https://stackoverflow.com/questions/68491889/execcondition-doesnt-prevent-start-of-service
• https://unix.stackexchange.com/questions/659647/execcondition-doesnt-prevent-start-of-service
• https://stackoverflow.com/questions/41067756/condition-on-script-status
• Add a service condition for $XDG_SESSION_TYPE systemd/systemd#15067

[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.