<div dir="ltr"><div>>
I find that /usr/lib/tmpfiles.d/nut-client.conf already exists
...</div><div>>
/usr/lib/tmpfiles.d/nut-common-tmpfiles.conf:8: Duplicate line for path "/run/nut", ignoring.
</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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@.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.</div><div><br></div><div>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.<br></div><div><br></div><div>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).</div><div><br></div><div>Jim <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 30, 2024 at 12:04 AM Rick Dicaire via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Mon, Jul 29, 2024 at 5:45 PM Tim Dawson <<a href="mailto:tadawson@tpcsvc.com" target="_blank">tadawson@tpcsvc.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>OK, looking at this on my RH8 test image . . .</p>
<p>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.</p></div></blockquote><div class="gmail_default" style="font-size:small">Tim, can you show output of systemctl list-unit-files| grep nut<br>Some service has to be enabled to call nut.target I should think.</div><div class="gmail_default" style="font-size:small">Also what version of the nut pkg is being used? I'm using nut-2.8.2-1.fc40.x86_64.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks</div></div></div>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>