Wants=network.target network-online.target
After=network.target network-online.target
Seems to be the case on RedHat8, and other RedHat based distros should match.
On July 28, 2024 1:56:49 PM EDT, Bill Gee <bgee at campercaver.net>
wrote:>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
>_______________________________________________
>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/b732b01f/attachment-0001.htm>