This is what I am running with at the moment:
[root@emp80 ups]# systemctl list-unit-files | grep -i nut
nut-driver-enumerator.path enabled
nut-driver-enumerator.service enabled
nut-driver@.service
indirect
nut-monitor.service
disabled
nut-server.service
disabled
nut-driver.target
disabled
nut.target enabled
nut-driver-enumerator.path enabled (and running) monitors for edits to
ups.conf, and flows changes into a driver restart. I can see this
happen if I edit ups.conf: the driver restarts.
The companion nut-driver-enumerator.service is a one-shot run service,
is also enabled to run at boot - this appears to run on EITHER when
triggered by nut-driver-enumerator.path OR on reboot (enabled), and I
believe generates the required nut-driver@eaton5sx.service.
nut.target enabled should then start nut-driver.target, nut-server and
nut-monitor (all are set to "wants" in the unit file).
At least, that is how I am reading it - if anyone else has other
pointers please let me know! :-)
Will see what happens over multiple reboots!
----- Message from Simon Wilson via Nut-upsuser
<nut-upsuser@alioth-lists.debian.net> ---------
Date: Wed, 30 Nov 2022 10:05:47 +1000
From: Simon Wilson via Nut-upsuser <nut-upsuser@alioth-lists.debian.net>
Reply-To: si...@simonandkate.net
Subject: Re: [Nut-upsuser] NUT service files on systemd
To: Jim Klimov <jimklimov+...@gmail.com>
Cc: Arnaud Quette via Nut-upsuser <nut-upsuser@alioth-lists.debian.net>
----- Message from Jim Klimov <jimklimov+...@gmail.com> ---------
Date: Wed, 30 Nov 2022 00:36:09 +0100
From: Jim Klimov <jimklimov+...@gmail.com>
Subject: Re: [Nut-upsuser] NUT service files on systemd
To: si...@simonandkate.net
Cc: Arnaud Quette via Nut-upsuser <nut-upsuser@alioth-lists.debian.net>
As recently noted in the lists, this was tracked
down to a Fedora 37 packaging bug: https://bugzilla.redhat.com/show_bug.cgi?
id=2127269
I did also recently revise build recipes and in particular use of PIDPATH
(not superficially suffixed with /nut now). Various precedents were messy
and confusing about it :-\
Thanks for the bug link - interesting, and reflects the challenges I
had with the 2.8.0-1.el8 package I found.
For context, what I worked through to resolve:
After the driver failed on 2.8.0 and seeing the permission error I
noticed nut-driver@.service had
"ExecStartPre=/usr/bin/systemd-tmpfiles --create
/usr/lib/tmpfiles.d/nut-client.conf" but also that file was missing.
When I checked /usr/lib/tmpfiles.d/ there was a nut-common.conf
(which I am not sure is actually used at all?).
Looking into the src I found what nut-client.conf was supposed to
contain and created /usr/lib/tmpfiles.d/nut-client.conf with the
required line pointing to /run/nut, with (on my RHEL system)
root:nut 0770 permissions. Systemd then runs that on service start,
creates the path with the correct permissions and the driver starts
OK, with a PID at /run/nut/usbhid-ups-eaton5sx.pid. Thumbs up.
I notice in the bug the suggested fix of "Uncommenting
STATEPATH=/var/run/nut in /etc/ups/upsd.conf" however I assume that
would require the correct permissions to already be available at
that location (although perhaps that is already done by install
script?). Correcting the ExecStartPre target has the advantage of
resolving it each time if it is not there or if permissions are
incorrect I believe.
Regarding enabled services - I think you should `systemctl enable
nut-server nut-monitor` and possibly `nut-driver@eaton5sx` explicitly.
Possibly - because i think this instance should have been enabled by
nut-driver-enumerator which registered it.
Thanks. Having nut.target enabled triggers the server and monitor
OK. It's the driver which does not seem to run each time (but does
*some* times, strangely). I testing for that and kicking it up if it
is not running at the moment, but will keep an eye on any relevant
comments to this list.
I did not yet inspect Fedora packaging and how it differs from `make
install` so can't quickly suggest more. OTOH would first suspect that new
recipe inherits parts of what was used for 2.7.4 and before, which might
pull in another direction than new in-project abilities.
Jim
Thanks again Jim.
On Tue, Nov 29, 2022, 13:14 Simon Wilson via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:
I've installed nut and nut-client 2.8.0 on my systemd server (had some
fun with the 2.8.0-1.el8 packages not correctly generating /var/run
due to an incorrect /usr/lib/tmpfiles.d entry (nut-common.conf instead
of nut-client.conf and pointing to /var/run/nut/nut) but that's a
story for another day - I worked around that).
My question is about systemd service files...
The 2.8.0 service files are different from 2.7.4 - and while I have
read the 2.8.0 documentation I am not clear on which of the various
.service and .target files should be set to autostart.
Immediately after install systemd had nut like this:
[root@emp80 ~]# systemctl list-unit-files | grep -i nut
nut-driver-enumerator.path disabled
nut-driver-enumerator.service disabled
nut-driver@.service disabled
nut-monitor.service disabled
nut-server.service disabled
nut-driver.target disabled
nut.target disabled
In 2.8.0 I have a configured ups.conf. I have not created or edited
any .service or .target unit-files, all are as standard. Editing
ups.conf resulted in nut-driver@eaton5sx.service correctly, and
systemctl start nut-driver@eaton5sx.service runs fine, as does
'upsdrvctl start'.
Then starting nut-server.service and nut-monitor.service gets me to a
fully operational state. After a reboot, nothing was auto-started, but
manually starting everything (driver, server, monitor) worked - so PID
files/locations are OK.
I'm now trying to work out what to "enable" for systemd autostart on
boot, and having mixed results.
I'm setup as follows at the moment, but am not sure if this is correct
for what should be enabled for autostart on reboot as sometimes the
driver does not start and has to be manually triggered into life.
[root@emp80 ~]# systemctl list-unit-files | grep -i nut
nut-driver-enumerator.path disabled
nut-driver-enumerator.service disabled
nut-driver@.service disabled
nut-monitor.service disabled
nut-server.service disabled
nut-driver.target enabled
nut.target enabled
What should be set to start with "systemctl enable ...."? Can someone
with a fully working systemd 2.8.0 setup please tell me what they have?
Thanks
Simon
--
Simon Wilson
M: 0400 12 11 16
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
----- End message from Jim Klimov <jimklimov+...@gmail.com> -----
----- End message from Simon Wilson via Nut-upsuser
<nut-upsuser@alioth-lists.debian.net> -----
--
Simon Wilson
M: 0400 12 11 16
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
