Bug 1187286
Summary: | Package nut does not creare directory /var/run/nut | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Gianluca Amato <amato> |
Component: | nut | Assignee: | Michal Hlavinka <mhlavink> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | ahabig, mhlavink, orion, vasy |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | nut-2.7.2-3.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-04-01 01:58:11 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
Gianluca Amato
2015-01-29 17:26:46 UTC
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[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 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. 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. https://admin.fedoraproject.org/updates/nut-2.7.2-3.el7 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). 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. 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. |