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