> 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 [email protected] 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 < [email protected]> wrote: > On Mon, Jul 29, 2024 at 5:45 PM Tim Dawson <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
