<html><head></head><body><div dir="auto">Wants=network.target network-online.target<br>After=network.target network-online.target<br><br>Seems to be the case on RedHat8, and other RedHat based distros should match.</div><br><br><div class="gmail_quote"><div dir="auto">On July 28, 2024 1:56:49 PM EDT, Bill Gee <bgee@campercaver.net> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><div dir="auto">These files came from the distro package. I did not change anything myself. Systemd newbie here ...<br><br>So the detailed question is - Exactly what change is needed to add the network-target dependency? I suspect it is not enough to simply remove the comment symbol on those two lines.<hr>Bill Gee<br><br>On 7/28/24 10:10, Tim Dawson wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><div dir="auto">Seems like you would also want the "network-target" dependency, since nut will likelynfail without networking being up. (This would also explwin why the sysctl start ... works after boot, but not during . . .<br><br><br>On July 28, 2024 10:37:15 AM EDT, Bill Gee <bgee@campercaver.net> wrote:<br><br> I have also been having this problem. Checking a few of the files<br> that Jim mentions, I find the following content. This is on Fedora<br> 40 and the nut package is 2.8.2-1.fc40. As Rick reports, running<br> "systemctl start nut-server.service" makes it all happy. I just have<br> to remember to do that whenever I reboot the system.<br><br> I find no disabled services related to nut. If any of them were<br> masked, then they should not be startable at all.<br><br> /usr/lib/systemd/system/nut.target =========<br> # Network UPS Tools (NUT) systemd integration<br> # Copyright (C) 2011-2023 by NUT contirbutors<br> # Distributed under the terms of GPLv2+<br> # See <a href="https://networkupstools.org/">https://networkupstools.org/</a> <<a href="https://networkupstools.org/">https://networkupstools.org/</a>><br> # and <a href="https://github.com/networkupstools/nut/">https://github.com/networkupstools/nut/</a><br> <<a href="https://github.com/networkupstools/nut/">https://github.com/networkupstools/nut/</a>><br><br> [Unit]<br> Description=Network UPS Tools - target for power device drivers,<br> data server and monitoring client (if enabled) on this system<br> After=local-fs.target nut-driver.target nut-server.service<br> nut-monitor.service<br> Wants=local-fs.target nut-driver.target nut-server.service<br> nut-monitor.service<br> # network.target<br><br> [Install]<br> WantedBy=multi-user.target<br><br><br> /usr/lib/systemd/system/nut.target =========<br> # Network UPS Tools (NUT) systemd integration<br> # Copyright (C) 2011-2023 by NUT contirbutors<br> # Distributed under the terms of GPLv2+<br> # See <a href="https://networkupstools.org/">https://networkupstools.org/</a> <<a href="https://networkupstools.org/">https://networkupstools.org/</a>><br> # and <a href="https://github.com/networkupstools/nut/">https://github.com/networkupstools/nut/</a><br> <<a href="https://github.com/networkupstools/nut/">https://github.com/networkupstools/nut/</a>><br><br> [Unit]<br> Description=Network UPS Tools - target for power device drivers on<br> this system<br> After=local-fs.target<br> # network.target<br> PartOf=nut.target<br><br> [Install]<br> WantedBy=nut.target<hr> Bill Gee<br><br> On 7/28/24 08:01, Jim Klimov via Nut-upsuser wrote:<br><br> For general troubleshooting, take a look at `journalctl -xln`<br> (started as `root`) to see details of systemd unit state<br> transitions. It is as close as I could get to guessing (still)<br> why the framework decides to do some things it does.<br><br> I wonder if the packaging misses (or did not activate) a<br> dependency definition to start NUT in the first place. Vanilla<br> code includes several `*.target` unit files, namely `nut.target`<br> as the umbrella which `Wants=local-fs.target nut-driver.target<br> nut-server.service nut-monitor.service` and is<br> `WantedBy=multi-user.target`, and `nut-driver.target` which<br> `nut-driver@*.service` instances managed by NDE<br> <a href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a> <<a href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a>> <<a href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a> <<a href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a>>> can claim to be `WantedBy`.<br><br> The expected state is, following clues from<br> <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment</a> <<a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment</a>> <<a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment</a> <<a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests#replacing-a-systemd-deployment</a>>> that the modern-Linux-distro packaging would deliver the unit files, run `|systemctl daemon-reload|`, maybe explicitly run `|systemd-tmpfiles --create|` (otherwiseOS boot or start-up of service units should take care of this), and `|systemctl disable|` + `|systemctl enable|` the delivered units, making them known and registering them with systemd dependency tree (notably the `WantedBy=multi-user.target`part of the `nut.target` umbrella unit). They may use or not a <a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html">https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html</a> <<a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html">https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html</a>> <<a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html">https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html</a> <<a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html">https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html</a>>> file for this (currently vanilla NUT sources do not ship one).<br><br> Also note that individual units (services, targets, ...) may be<br> explicitly `disable`'d or even `mask`'ed as you manage your<br> system, so that may also come into play.<br><br> Hope this helps,<br> Jim Klimov<br><br><br><br> On Sun, Jul 28, 2024 at 12:54 AM Rick Dicaire via Nut-upsuser<br> <nut-upsuser@alioth-lists.debian.net<br> <<a href="mailto:nut-upsuser@alioth-lists.debian.net">mailto:nut-upsuser@alioth-lists.debian.net</a><br> <<a href="mailto:nut-upsuser@alioth-lists.debian.net">mailto:nut-upsuser@alioth-lists.debian.net</a>>>> wrote:<br><br> Hi folks, I'm having an issue with getting nut-server to start at<br> boot on a freshly installed Fedora 40 desktop. Seems once the<br> machine is up, I can manually start with systemctl start nut-server<br> and everythings fine.<br><br> dnf info nut<br> Last metadata expiration check: 2:08:11 ago on Sat 27 Jul 2024<br> 03:48:13 PM EDT.<br> Installed Packages<br> Name : nut<br> Version : 2.8.2<br> Release : 1.fc40<br> Architecture : x86_64<br> Size : 12 M<br> Source : nut-2.8.2-1.fc40.src.rpm<br> Repository : @System<br> From repo : updates<br> Summary : Network UPS Tools<br> URL : <a href="https://www.networkupstools.org/">https://www.networkupstools.org/</a><br> <<a href="https://www.networkupstools.org/">https://www.networkupstools.org/</a>><br> <<a href="https://www.networkupstools.org/">https://www.networkupstools.org/</a><br> <<a href="https://www.networkupstools.org/">https://www.networkupstools.org/</a>>><br> License : GPL-2.0-or-later AND GPL-3.0-or-later<br> Description : These programs are part of a developing project to<br> monitor the assortment<br> : of UPSes that are found out there in the field. Many<br> models have serial<br> : ports of some kind that allow some form of state<br> checking. This<br> : capability has been harnessed where possible to<br> allow for safe shutdowns,<br> : live status tracking on web pages, and more.<br><br><br> I've tried with specific LISTEN lines in upsd.conf, also tried<br> without one specified. Same result, service doesn't start at boot.<br> No apparent errors reported either:<br><br> systemctl status nut-server<br> ○ nut-server.service - Network UPS Tools - power devices information<br> server<br> Loaded: loaded (/usr/lib/systemd/system/nut-server.service;<br> enabled; preset: disabled)<br> Drop-In: /usr/lib/systemd/system/service.d<br> └─10-timeout-abort.conf<br> Active: inactive (dead)<br><br> In /usr/lib/systemd/system/nut-server.service there's mention of:<br><br> # The `upsd` is a networked service (even if bound to a `localhost`)<br> # so it requires that the OS has some notion of networking already.<br> # Extending the unit does not require *this* file to be edited, you<br> # can instead drop in an additional piece of configuration, e.g. to<br> # require that NUT data server only starts after external networking<br> # is configured (usable IP addresses appear in the system) you can<br> # add a `/etc/systemd/system/nut-server.service.d/network.conf`<br> with:<br> # [Unit]<br> # Requires=network-online.target<br> # After=network-online.target<br><br> However adding this file with those three lines (uncommented yes)<br> still results in no nut-server running, with and without LISTEN<br> lines in upsd.conf.<br><br> Since there's no issues starting the service manually after reboot,<br> I feel like this is some kind of systemd thing as opposed to a nut<br> config issue.<br><br> Various config file contents:<br><br> nut.conf<br> MODE=netserver<br><br> ups.conf<br> maxretry = 3<br> [cp1500]<br> driver = usbhid-ups<br> port = auto<br> vendorid = 0764<br> pollinterval = 5<br> desc = "toshiba: TV, roku, switch"<br><br> upsd.conf<br> LISTEN 0.0.0.0 3493<br><br> upsmon.conf<br> MONITOR cp1500@localhost 1 monuser monuserpass primary<br> MINSUPPLIES 1<br> SHUTDOWNCMD "/sbin/shutdown -h +0"<br> POLLFREQ 5<br> POLLFREQALERT 5<br> HOSTSYNC 15<br> DEADTIME 15<br> POWERDOWNFLAG "/etc/killpower"<br> NOTIFYMSG ONLINE "UPS %s on line power"<br> NOTIFYMSG ONBATT "UPS %s on battery"<br> NOTIFYMSG LOWBATT "UPS %s battery is low"<br> NOTIFYMSG FSD "UPS %s: forced shutdown in progress"<br> NOTIFYMSG COMMOK "Communications with UPS %s established"<br> NOTIFYMSG COMMBAD "Communications with UPS %s lost"<br> NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"<br> NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"<br> NOTIFYMSG NOCOMM "UPS %s is unavailable"<br> NOTIFYMSG NOPARENT "upsmon parent process died - shutdown<br> impossible"<br> NOTIFYFLAG ONLINE SYSLOG+WALL<br> NOTIFYFLAG ONBATT SYSLOG+WALL<br> NOTIFYFLAG LOWBATT SYSLOG+WALL<br> NOTIFYFLAG FSD SYSLOG+WALL<br> NOTIFYFLAG COMMOK SYSLOG+WALL<br> NOTIFYFLAG COMMBAD SYSLOG+WALL<br> NOTIFYFLAG SHUTDOWN SYSLOG+WALL<br> NOTIFYFLAG REPLBATT SYSLOG+WALL<br> NOTIFYFLAG NOCOMM SYSLOG+WALL<br> NOTIFYFLAG NOPARENT SYSLOG+WALL<br> OFFDURATION 30<br> RBWARNTIME 43200<br> NOCOMMWARNTIME 300<br> FINALDELAY 5<br><br> Ultimately I need this service to listen on lan interface as I query<br> it from other lan machine.<br><br> Can anyone provide any insight on my issue?<br><br> Thanks<hr> Nut-upsuser mailing list<br> Nut-upsuser@alioth-lists.debian.net<br> <<a href="mailto:Nut-upsuser@alioth-lists.debian.net">mailto:Nut-upsuser@alioth-lists.debian.net</a><br> <<a href="mailto:Nut-upsuser@alioth-lists.debian.net">mailto:Nut-upsuser@alioth-lists.debian.net</a>>><br> <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a>><br> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a>>><hr> Nut-upsuser mailing list<br> Nut-upsuser@alioth-lists.debian.net<br> <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a>><hr> Nut-upsuser mailing list<br> Nut-upsuser@alioth-lists.debian.net<br> <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br> <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a>><br><br><div class="k9mail-signature">-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.<hr>Nut-upsuser mailing list<br>Nut-upsuser@alioth-lists.debian.net<br><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br></div></div></blockquote><div dir="auto"><hr>Nut-upsuser mailing list<br>Nut-upsuser@alioth-lists.debian.net<br><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br></div></pre></blockquote></div><div dir="auto"><div class='k9mail-signature'>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></body></html>