- Message from Bill Gee -
Date: Tue, 29 Nov 2022 19:25:19 -0600
From: Bill Gee
Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
To: Jim Klimov
Cc: Arnaud Quette via Nut-upsuser
I got it to run, but what a mess ...
Yes, I am running
I got it to run, but what a mess ...
Yes, I am running systemctl daemon-reload and systemctl restart
nut-server after each change I make.
I created /usr/lib/tmpfiles.d/nut-client.conf The owner is root:root
and permissions are 0644. The contents are
# State file (e.g. upsd to driver)
- Message from Jim Klimov -
Date: Wed, 30 Nov 2022 00:36:09 +0100
From: Jim Klimov
Subject: Re: [Nut-upsuser] NUT service files on systemd
To: si...@simonandkate.net
Cc: Arnaud Quette via Nut-upsuser
As recently noted in the lists, this was tracked
down to a
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
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
> The nut user does not have write permissions at /run.
Note that /run is linked as /var/run and the nut user DOES have write
permissions there.
These two
Yesterday I upgraded one of my systems from Fedora 36 to Fedora 37. NUT
was upgraded to version 2.8.0. It no longer runs.
At first I thought it was because of the XFCE Power Manager program.
That program finds the UPS with no problem. I thought maybe the two
programs were competing for the
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
