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