Red Hat Bugzilla – Bug 1187286
Package nut does not creare directory /var/run/nut
Last modified: 2017-07-07 14:34:29 EDT
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):
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"
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)
The driver starts and no error message is displayed
To fix the problem, create directory /var/run/nut and assign it to user nut and group nut.
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
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.
For me, use nut without monitor:
# systemctl status nut-driver.service
фев 10 16:59:16 inf upsdrvctl: Can't chdir to /var/run/nut: No such file or directory
фев 10 16:59:16 inf upsdrvctl: Network UPS Tools - APC Smart protocol driver 3.1 (2.7.2)
фев 10 16:59:16 inf upsdrvctl: APC command table version 3.1
фев 10 16:59:16 inf upsdrvctl: Driver failed to start (exit status=1)
фев 10 16:59:16 inf upsdrvctl: Network UPS Tools - UPS driver controller 2.7.2
фев 10 16:59:16 inf systemd: nut-driver.service: control process exited, code=exited status=1
фев 10 16:59:16 inf systemd: Failed to start Network UPS Tools - power device driver controller.
фев 10 16:59:16 inf systemd: Unit nut-driver.service entered failed state.
# mkdir /var/run/nut
# chown nut.nut /var/run/nut
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.
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 ?
nut-2.7.2-3.el7 has been submitted as an update for Fedora EPEL 7.
* 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).
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.
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
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
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.