[Nut-upsuser] NUT service files on systemd

[Simon Wilson]

----- 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