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

Sun Jul 28 14:01:48 BST 2024

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)
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
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
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> 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/
> 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
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240728/2b24671f/attachment.htm>