[Nut-upsuser] NUT service files on systemd

[Jim Klimov]

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

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.

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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20221130/e8883393/attachment-0001.htm>