Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1187286 - Package nut does not creare directory /var/run/nut
Package nut does not creare directory /var/run/nut
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: nut (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-01-29 12:26 EST by Gianluca Amato
Modified: 2017-07-07 14:34 EDT (History)
4 users (show)

See Also:
Fixed In Version: nut-2.7.2-3.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-31 21:58:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gianluca Amato 2015-01-29 12:26:46 EST
Description of problem:
Installing package nut does not creare the directory /var/run/nut. Hence, the service nut-driver does not start.

Version-Release number of selected component (if applicable): 

2.7.2-2.el7

How reproducible:

Fully reproducible.

Steps to Reproduce:
1. Modify file /etc/ups/nut.conf replacing "MODE=none" with "MODE=standalone"
2. Insert a valid configuration in /etc/ups/ups.conf (I tried with riello_usb and snmp-ups)
3. Start UPS drivers with "upsdrvctl start"

Actual results:

The driver does not start and the following is displayed:

Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Generic SNMP UPS driver 0.72 (2.7.2)
Can't chdir to /var/run/nut: No such file or directory
Driver failed to start (exit status=1)

Expected results:

The driver starts and no error message is displayed

Additional info:

To fix the problem, create directory /var/run/nut and assign it to user nut and group nut.
Comment 1 Michal Hlavinka 2015-01-30 13:55:50 EST
There are nut-monitor, nut-server and nut-driver services

instead of upsdrvctl start, for standalone mode run 
systemctl start nut-monitor.service nut-server.service

if you want it to start automatically during boot, use "enable" instead of "start" in previous command
Comment 2 Gianluca Amato 2015-02-03 09:59:14 EST
Actually, starting nut-monitor creates the directory /var/run/nut and then everything works. However, starting nut-server alone is not enough (the directory is not created).

I still think this is a bad behavior. I should not be forced to start nut-monitor if I only want nut-server. Just adding a /var/run/nut directory to the nut package would solve the problem.
Comment 3 Vasyliy Borisov 2015-02-10 11:11:17 EST
For me, use nut without monitor:
# systemctl status nut-driver.service
фев 10 16:59:16 inf upsdrvctl[32598]: Can't chdir to /var/run/nut: No such file or directory
фев 10 16:59:16 inf upsdrvctl[32598]: Network UPS Tools - APC Smart protocol driver 3.1 (2.7.2)
фев 10 16:59:16 inf upsdrvctl[32598]: APC command table version 3.1
фев 10 16:59:16 inf upsdrvctl[32598]: Driver failed to start (exit status=1)
фев 10 16:59:16 inf upsdrvctl[32598]: Network UPS Tools - UPS driver controller 2.7.2
фев 10 16:59:16 inf systemd[1]: nut-driver.service: control process exited, code=exited status=1
фев 10 16:59:16 inf systemd[1]: Failed to start Network UPS Tools - power device driver controller.
фев 10 16:59:16 inf systemd[1]: Unit nut-driver.service entered failed state.

after 
# mkdir /var/run/nut
# chown nut.nut /var/run/nut

nut working
Comment 4 Orion Poplawski 2015-02-20 18:38:32 EST
nut-client (required by nut) has:

# cat /etc/tmpfiles.d/nut-client.conf
D    /var/run/nut 0750 nut nut -

which will create the directory on boot. 

It should be installed in /usr/lib/tmpfiles.d, but that's a minor point.  See
http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

systemd is supposed to watch for those files and act on them when installed, but perhaps the version in RHEL7 is too old to do it automatically.
Comment 5 Gianluca Amato 2015-02-23 04:12:37 EST
I have the file /etc/tmpfiles.d/nut-client.conf. Moreover, "man tmpfiles.d" confirms that systemd should read the file and create the directory. However, this does not happen.

If I call "systemd-tmpfiles --create" manually, then directores are created. So I think Orion is right, systemd does not watch the directory /etc/tmpfiles.d for changes (at least in the CentOS 7 version). Is "systemd-tmpfiles" supposed to be called manually by the system at startup?

In any case, which is the advantage to have /var/run/nut created by systemd-tmpfiles instead of it being part of the nut-client package itself ?
Comment 6 Fedora Update System 2015-03-06 06:03:00 EST
nut-2.7.2-3.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/nut-2.7.2-3.el7
Comment 7 Fedora Update System 2015-03-08 18:48:57 EDT
Package nut-2.7.2-3.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing nut-2.7.2-3.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1168/nut-2.7.2-3.el7
then log in and leave karma (feedback).
Comment 8 Fedora Update System 2015-03-31 21:58:11 EDT
nut-2.7.2-3.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Habig, Alec 2017-07-07 14:34:29 EDT
Hi folks,

Sorry for the bug necromancy, but there's a problem with this patch.  Could start a new bug instead?  Will do so if you want.  But the discussion is all here, using .nut-2.7.2-3.el7 as released in Comment 8.  So here goes.

Turns out that /etc/tmpfiles.d/nut-client.conf is not part of nut-client, the rpm instead contains:

  rpm -ql nut-client | grep nut-run.conf
  /usr/lib/tmpfiles.d/nut-run.conf

Which the tmpfile service reads at startup, making /var/run/nut ok. So your "does it work" tests work.  I think.  Worked sometimes (first few reboots of a new machine), then it didn't.  A race condition between the tmpfiles service scanning all its dirs and the nut service starting perhaps?  systemd's still a bit black magic to me.  

Anyway, the systemd service files

  /usr/lib/systemd/system/nut-driver.service
  /usr/lib/systemd/system/nut-monitor.service

have the line

  ExecStartPre=-/usr/bin/systemd-tmpfiles --create /etc/tmpfiles.d/nut-run.conf

so upon service start systemd complains:

  systemd-tmpfiles: Failed to open '/etc/tmpfiles.d/nut-run.conf', ignoring: No such file or directory

because rpm has put the file in /usr/lib not in /etc

Changing the --create target in these service files to the rpm-installed /usr/lib/tmpfiles.d/nut-run.conf lets the service start ok without complaints. 



One related bug.  As installed out of the box, the nut rpm provides upsmon.conf, containing the line

  POWERDOWNFLAG /etc/ups/killpower

However, nut cannot write to the (root-owned) /etc/ups directory, so on event of a powerdown event, you get:

  upsmon: Failed to create power down flag!

Changing this line to

  POWERDOWNFLAG /var/run/nut/killpower

lets the shutdown script do the needed step of dropping the load as the last step of shutdown, enabling the machine to come back after power is restored, since /var/run/nut was created as owned by nut, so is a good place to drop the flagfile.

Note You need to log in before you can comment on or make changes to this bug.