[Nut-upsuser] NUT service files on systemd
Simon Wilson
simon at simonandkate.net
Wed Nov 30 10:44:52 GMT 2022
This is what I am running with at the moment:
[root at emp80 ups]# systemctl list-unit-files | grep -i nut
nut-driver-enumerator.path enabled
nut-driver-enumerator.service enabled
nut-driver at .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 at 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 at alioth-lists.debian.net> ---------
Date: Wed, 30 Nov 2022 10:05:47 +1000
From: Simon Wilson via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
Reply-To: simon at simonandkate.net
Subject: Re: [Nut-upsuser] NUT service files on systemd
To: Jim Klimov <jimklimov+nut at gmail.com>
Cc: Arnaud Quette via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
> ----- Message from Jim Klimov <jimklimov+nut at gmail.com> ---------
> Date: Wed, 30 Nov 2022 00:36:09 +0100
> From: Jim Klimov <jimklimov+nut at gmail.com>
> Subject: Re: [Nut-upsuser] NUT service files on systemd
> To: simon at simonandkate.net
> Cc: Arnaud Quette via Nut-upsuser <nut-upsuser at 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 at .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 at 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 at 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 at emp80 ~]# systemctl list-unit-files | grep -i nut
>>> nut-driver-enumerator.path disabled
>>> nut-driver-enumerator.service disabled
>>> nut-driver at .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 at eaton5sx.service correctly, and
>>> systemctl start nut-driver at 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 at emp80 ~]# systemctl list-unit-files | grep -i nut
>>> nut-driver-enumerator.path disabled
>>> nut-driver-enumerator.service disabled
>>> nut-driver at .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 at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>
>
> ----- End message from Jim Klimov <jimklimov+nut at gmail.com> -----
----- End message from Simon Wilson via Nut-upsuser
<nut-upsuser at alioth-lists.debian.net> -----
--
Simon Wilson
M: 0400 12 11 16
More information about the Nut-upsuser
mailing list