Bug 1187286 - Package nut does not creare directory /var/run/nut
Package nut does not creare directory /var/run/nut
Product: Fedora EPEL
Classification: Fedora
Component: nut (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
Depends On:
  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:
Last Closed: 2015-03-31 21:58:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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): 


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.

# 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

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.
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:
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

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


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.