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

Tim Dawson tadawson at tpcsvc.com
Sun Jul 28 16:10:20 BST 2024


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>


More information about the Nut-upsuser mailing list