Setting non-root device node permissions causes nut-driver.service to fail to start

[hexadecagram]

Hello,

ArchLinux user here.

If I use udev to set a user/group on the device node for my UPS, nut-driver.service doesn't start up on boot. If I then login and restart nut-driver.service, it works.

The systemd functionality described in this blog supposedly worked at one time (I never tried it myself).

After much trial and error, I set After=network-online.target and Requires=network-online.target for both nut-driver.service and nut-server.service (the latter of which should have those configurations regardless, because upsd will fail to start if the network is not online). Boom, it works. I tried quite a few unit files before that, all the way up the chain to upower.service. Nothing else worked.

I think a more appropriate fix would be to add something like the following in nut-driver.service (which also works). This will work for now but I think the ideal solution would to be to remove the nut-driver.service dependency in nut-server.service and work it into udev so that drivers are reloaded when devices are hotplugged.

[Service]
Restart=on-failure
RestartSec=10

[clepple]

@aquette, can you weigh in on this? I think there have been systemd-related discussions since this was posted.

[aquette]

@clepple indeed, there were several improvements recently that are staging as pull requests (see #330), including similar Req/After network-online.target. However, I've not played with that myself, so I'll defer to @jimklimov to further comment...

[jimklimov]

Ok, so just for a bit more perspective: the PR #330 (and its predecessor #229) deal with this issue form a different angle - while the original NUT approach with legacy roots in root-run init-scripts was to start all drivers as one unit, these PRs change it to allow each driver to be served by an individual unit so they fail (due to unavailability, code errors, etc.) separately and independently, and can have individual dependencies set up (perhaps via the nut-driver@${devicename}.d/ custom subdirectories).

The majority of NUT drivers themselves do not need networking, except those which use it as media for the power-device connection (SNMP, NetXML, IPMI, perhaps some others). It is the upsd which relays local drivers' data to the common networked protocol, and its clients like upsmon, that do need the networking stack as a fundamental requirement (but even then, for many small deployments a localhost connection suffices). It is arguable if starting a nut-server (upsd) makes sense if no local drivers are running -- some would consider it an error to report as a service fault, others (like the hot-plug case mentioned above) would consider it a way to show that the nut-server works and just no drivers are attached (e.g. an upsc -l would show nothing - but no errors either). It is more certain another way around - that a running nut-driver (monolithic or instantiated variant) should bring up the nut-server generally (if networking is available, etc.) :)

The original post did not detail what UPS type @hexadecagram had and so it is unclear if his nut-driver services need to start after networking or independent of it. However if there is a device node ownership involved, I'd guess it is a local-connection protocol (USB or serial), so ordering around networking is not an issue.

Finally, it was not noted if the customized device node ownership were matched with the NUT driver setup (user and group config fields IIRC and/or command-line args) - this is something to take care of too.

At the moment I think that the "boom it works" effect was due to timing and/or racing with some other units - perhaps his drivers need to be ordered after (and require) udev services or somesuch instead (so device nodes are created at all and/or the expected rights are applied to them), and indeed confirmation of this idea might be valuable input for evolution of PR#330 too.