Bug 2143442

Summary:	Unable to monitor USB UPS - probably wrong hardcoded path to socket
Product:	[Fedora] Fedora	Reporter:	Marek Greško <marek.gresko>
Component:	nut	Assignee:	Charles R. Anderson <cra>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	37	CC:	cra, crow, dominique, dwhile, james, mhlavink, orion, pizza, scott, stuart
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-12-03 17:37:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marek Greško 2022-11-16 23:33:05 UTC

Description of problem:
The nut-server is not able to connect to usb driver. The most probable cause is that driver is trying to create socket directly in /var/run directory where it does not have permission to write. It should probably be modofied to create the socket in the /var/run/nut directory.

When I run /usr/sbin/usbhid-ups -a ups -u root -DD

then the socket is created in /var/run, not in /var/run/nut. I dod not find any configuration option to change it. It seems to be hardcoded.

Version-Release number of selected component (if applicable):
nut-2.8.0-4.fc37.x86_64


How reproducible:


Steps to Reproduce:
1. Configure usb ups.
2. Run nut.
3. Nut is unable to connect to ups. the upsc ups command displays Error: Driver not connected

Actual results:
Nut is not able to monitor UPS.

Expected results:
Nut is able to monitor UPS.


Additional info:

Comment 1 Marek Greško 2022-11-16 23:36:32 UTC

Maybe the option --with-altpidpath=/var/run/nut should be added to the configure when compiling.

Comment 2 Marek Greško 2022-11-16 23:41:33 UTC

And also --with-statepath=/var/run/nut.

Comment 3 Marek Greško 2022-11-17 23:37:08 UTC

I tried to rebuild the rpms with these configure parameters:

    --with-statepath=/run/nut \
    --with-pidpath=/run \
    --with-altpidpath=/run/nut \

Current state is:

systemctl status nut-monitor displays fopen /run/upsmon.pid: No such file or directory

and /usr/lib/tmpfiles.d/nut-common.conf contains

d /run/nut/nut 0770 nut dialout - -
X /run/nut/nut
d /run/nut 0770 nut dialout - -
X /run/nut

So I am not sure what are the correct parameters. Probably

    --with-statepath=/run/nut \
    --with-pidpath=/run/nut \

The Error: Driver not connected was related to not running nut-driver service. In the 2.8.0 version you should enable nut-driver. But I did not test with original packages. Maybe it would not work since it creates socket in /run/nut. It would not create it in /run because of permissions.

Comment 4 Marek Greško 2022-11-18 00:08:20 UTC

I tested with

    --with-statepath=/run/nut \
    --with-pidpath=/run/nut \

The results were quite interesting. nut-monitor tried to search for pid file in the correct directory /run/nut instead of /run, but /usr/lib/tmpfiles.d/nut-common.conf contained only

d /run/nut/nut 0770 nut dialout - -
X /run/nut/nut

instead of

d /run/nut 0770 nut dialout - -
X /run/nut

So this is probably also not the exact combination required. Or some patch is required.

Moreover I found out the file name is /usr/lib/tmpfiles.d/nut-common.conf but the service units look for /usr/lib/tmpfiles.d/nut-client.conf

Comment 5 Charles R. Anderson 2022-12-03 17:33:57 UTC

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

Comment 6 Charles R. Anderson 2022-12-03 17:34:14 UTC

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

Comment 7 Charles R. Anderson 2022-12-03 17:34:38 UTC

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

Comment 8 Charles R. Anderson 2022-12-03 17:35:58 UTC

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

Comment 9 Charles R. Anderson 2022-12-03 17:37:18 UTC


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