[Nut-upsuser] Fedora 40 nut-server not starting at boot

[Jim Klimov]

> I find that /usr/lib/tmpfiles.d/nut-client.conf already exists ...
> /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf:8: Duplicate line for path
"/run/nut", ignoring.

It seems the package delivers two files, one from vanilla another from
their recipe's legacy (from before NUT upstream dealt with systemd itself)?
Not sure it is a show-stopping problem, the extra instance of a path
definition just gets ignored, it seems. At least, Bill's second
"screenshot" from the logs has start-up succeeded despite the message.

What does look strange is that at "16:06:49" the `nut-server` was stopped
by "Signal 15" (SIGTERM). The tmpfiles message was 3 minutes prior, so I
suppose `upsd` ran for about 3 minutes and then somebody stopped it. Either
some competitor (a differently started `upsd`? IIRC only drivers kill off
siblings assuming they froze), or systemd itself if some required
dependency was not fulfilled.

By default (in vanilla sources) the `nut-server.service`
"Requires=network.target" (so could be cycled if network was), and is
"PartOf=nut.target" (so could be cycled if "nut.target" gets restarted, e.g
due to its dependencies not fulfilled, although by default it only "Wants"
stuff so systemd does best-effort ordering but not fatal for start-ups).

The assumptions above also touch on Tim's report about added dependencies
in nut.target on the network units. My understanding is that systemd starts
multi-user.target as the ultimate milestone for the system, nut.target
registers itself as a dependency for that, and in turn "Wants+After" some
NUT and some system-provided units. Such NUT units as `nut-server.service`
"Require" networking (full or just "network-online" for localhost-only
serving, if uncommented or passed via drop-in files). Some of the
nut-drivers at .service instances generated by NDE may also require networking
(if they are for snmp, netxml, ipmi and similar networked-media drivers),
while others have no reason to wait for the net or even expect it ever
appears (serial, USB, ... drivers). There is a known chicken-and-egg
situation about dummy or clone drivers used to proxy (part of) a device
served by another driver on the same system - upsd normally soft-depends on
nut-driver.target, and each driver depends on upsd, so that dummy instance
has to be hacked around.

Note that you can configure `upsd` to "LISTEN *" so it would try binding to
"ANY" IP address for both IPv6 (::0) and IPv4 (0.0.0.0) by default, so
minimally depending on actual IP addresses set up on the system at the time
it starts.

The `dialout` group is probably a legacy trick, at least something like it
is on many Unix-like OSes, where serial ports by default are ready to be
owned by modem/getty/... software. IIRC it was easier for NUT to
make-believe it is a modem program (by being in the group) than for users
to re-own particular /dev/tty* nodes to a `nut` group (and have it persist,
where devfs is a virtual filesystem, made anew with every reboot).

Jim


On Tue, Jul 30, 2024 at 12:04 AM Rick Dicaire via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> On Mon, Jul 29, 2024 at 5:45 PM Tim Dawson <tadawson at tpcsvc.com> wrote:
>
>> OK, looking at this on my RH8 test image . . .
>>
>> The first thing that I note, is that the *only* thing that needed to be
>> set to "enabled" in systemctl (IE "systemctl enable ....") is the
>> nut.target entry.
>>
> Tim, can you show output of systemctl list-unit-files| grep nut
> Some service has to be enabled to call nut.target I should think.
> Also what version of the nut pkg is being used? I'm
> using nut-2.8.2-1.fc40.x86_64.
>
> Thanks
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240730/b5a2f6cb/attachment-0001.htm>