----- 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> -----
--
Simon Wilson
M: 0400 12 11 16