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>