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

Bill Gee bgee at campercaver.net
Sun Jul 28 18:56:49 BST 2024


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


More information about the Nut-upsuser mailing list