Bug 2127269

This is quite odd. Currently STATEPATH is set to /run/nut but on current systems /var/run is symlink to /run so /var/run/nut and /run/nut should be the same directory.
Unfortunately, I don't have UPS for testing, so can't try to reproduce this.
Please check:
1) /var/run is symlink to /run on your system
# ls -l /var/run
this should print something similar to:
lrwxrwxrwx. 1 root root 6 Dec 21  2021 /var/run -> ../run

2) try to run your modified reproducer NUT_STATEPATH=/var/run/nut -> NUT_STATEPATH=/run/nut
# NUT_STATEPATH=/var/run/nut /sbin/usbhid-ups -u nut -g dialout -a cyber -D
to see if it works

3) what other thing comes to mind is some SELinux policy that checks just the path, but does not care about the target being the same...
a) check label is correct
# restorecon -Rv /run/nut
b) if previous does not help, try with selinux in permissive mode:
# setenforce 0
this will change selinux to permissive mode (just until reboot) try the reproducer again, if it changes anything

thanks

My configuration worked with 2.7.4, broke while upgrading to fedora37 and nut 2.8.0.



Fatal error: unable to create listener socket

bind /var/run/usbhid-ups-srvups failed: Permission denied



This is when running usbhid-ups directly, so buildtime STATEPATH does not seem to work. Using NUT_STATEPATH and set it to eithet suggested paths and usbhid-ups starts.

The problem turns out is actually fixed in nut-2.8.0-5.fc37.x86_64

However it is not even queued for "testing" in Fedora37, so you will get nut-2.8.0-4.fc37.x86_64 which does set the wrong PID-path and STATEPATH.
Please submit nut-2.8.0-5.fc37.x86_64 for stable.

That said, the current package nut-2.8.0-5.fc37.x86_64 has other problems that needs to be adressed before stable.

The spec-file applies[2] a patch [1] which add:
```
ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-client.conf
```
to nut-driver@.service

However the part which should copy this file to the correct place [3] is commented out, so nut-driver@.service will currently also fail.

[1] https://src.fedoraproject.org/rpms/nut/blob/rawhide/f/nut-2.6.3-tmpfiles.patch
[2] https://src.fedoraproject.org/rpms/nut/blob/rawhide/f/nut.spec#_138
[3] https://src.fedoraproject.org/rpms/nut/blob/rawhide/f/nut.spec#_206

Is there any hotfix? I struggle with it since upgrade to Fedora 37.

(In reply to Václav Nováček from comment #5)
> Is there any hotfix? I struggle with it since upgrade to Fedora 37.

See the workaround under Additional Info in initial comment.  Just edit your upds.conf

(In reply to Stuart D Gathman from comment #6)
> (In reply to Václav Nováček from comment #5)
> > Is there any hotfix? I struggle with it since upgrade to Fedora 37.
> 
> See the workaround under Additional Info in initial comment.  Just edit your
> upds.conf

Uncommenting "STATEPATH /var/run/nut" in /etc/ups/upsd.conf doesn't help. Still getting:
Fatal error: unable to create listener socket

bind /var/run/usbhid-ups-ups failed: Permission denied

The only command that works is:
NUT_STATEPATH=/var/run/nut /sbin/usbhid-ups -u nut -g dialout -a cyber -D

nevetheless it never ends, there is a loop with..
   4.642950     [D1] upsdrv_updateinfo...
   5.393282     [D1] Got 0 HID objects...
   5.393322     [D1] Quick update...
   5.643159     [D1] upsdrv_updateinfo...
   6.393396     [D1] Got 0 HID objects...
   6.393443     [D1] Quick update...
   6.643363     [D1] upsdrv_updateinfo...
   7.393571     [D1] Got 0 HID objects...
   7.393603     [D1] Quick update...

I had to make two changes to get the driver working:

1. uncomment the "STATEPATH /var/run/nut" as already mentioned

2. create: /etc/systemd/system/nut-driver@.service.d/environ.conf
   with these two lines:

[Service]
Environment=NUT_STATEPATH=/var/run/nut

and finally do: systemctl daemon-reload

---

I think the default hardcoded path in /usr/sbin/usbhid-ups which is /var/run is causing the problem
and bugs 2143442 and 2143833 are closely related if not duplicates.

(In reply to Václav Nováček from comment #7)
> Uncommenting "STATEPATH /var/run/nut" in /etc/ups/upsd.conf doesn't help.
> Still getting:
> Fatal error: unable to create listener socket
> 
> bind /var/run/usbhid-ups-ups failed: Permission denied

Need to systemctl restart nut-server

Ah.  I have STATEPATH /run/nut in my upsd.conf

My STATEPATH in /etc/ups/upsd.conf was correct but I still could not get nut to start. The only thing that worked was starting usbhid-ups by hand:

NUT_STATEPATH=/var/run/nut /usr/sbin/usbhid-ups -a nutdev1

Afterwards nut-server could start, and be happy.

I grabbed nut-2.8.0-5 out of Koji.

The commented out part in the spec file, mentioned by Peter -- but its intent appears to be to install SOURCE3 as nut-common.tmpfiles, that the next line renames. It looks like it was intended to obliterate the ones that the package apparently installs, which is wrong.

I could not get the existing, commented out, "if" statement to evaluate to true, for some reason. Something about that if statement wasn't quite right on fc37, and the broken tmpfiles.d conf file was getting into the package. I didn't want to waste much time on that if statement, I just broomed the entire conditional statement out of the way and just copied SOURCE3 into tmpfiles.d

The resulting package appears to work for me:

# cat /usr/lib/tmpfiles.d/nut-common.conf
D    /run/nut 0770 root nut -

Everything appears to start, "upsc nutdev1" is giving me reasonable results.

*** This bug has been marked as a duplicate of bug 2143442 ***

*** Bug 2143442 has been marked as a duplicate of this bug. ***

I fixed all the issues of this bug and the duplicate closed bugs via pull request:

https://src.fedoraproject.org/rpms/nut/pull-request/12

Please apply to all appropriate branches.

The issues were numerous:

The systemd-tmpfiles call added to the systemd unit files as ExecStartPre was using the wrong configuration file name (nut-client.conf rather than nut-common.conf as shipped by upstream and in the latest package.)

tmpfiles.d/nut-common.conf as shipped by upstream was using the wrong paths--incorrectly appending /nut to @STATEPATH@ etc.
tmpfiles.d/nut-common.conf was also being regenerated by configure with the same wrong paths.   /nut should not be appended, because it is part of the @STATEPATH@ itself, so it was causing paths lke /run/nut/nut to be created.

tmpfiles.d/nut-common.conf was also using the incorrect owner for /run/nut.  It needs to be owned by root so that PID files can be written successfully by the daemons that write their PID files before dropping root privs.  This is enforced by SELinux--root cannot override permissions by default unless DAC_OVERRIDE is granted in the SELinux policy (which is undesirable--see https://danwalsh.livejournal.com/79643.html).

I've also made various other cleanups, such as consistently using the piddir macro to specify this directory path everywhere it is used.

Hi, thanks for looking into this. PR looks good. Did you test it? I don't have working UPS at the moment.

FEDORA-2022-ad272c9e2c has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ad272c9e2c

FEDORA-2022-e2342eb28e has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-e2342eb28e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e2342eb28e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-ad272c9e2c has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-ad272c9e2c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ad272c9e2c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-e2342eb28e has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-ad272c9e2c has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.