Description of problem: [root@zmhost baz]# systemctl restart munin-node.service Job failed. See system journal and 'systemctl status' for details. Version-Release number of selected component (if applicable): From munin-node log:- Process Backgrounded 2012/09/25-14:17:50 Couldn't open pid file "/var/run/munin/munin-node.pid" [No such file or directory]. So: [root@zmhost baz]# md /run/munin [root@zmhost baz]# systemctl restart munin-node.service [root@zmhost baz]# systemctl status munin-node.service munin-node.service - Munin Node Server. Loaded: loaded (/usr/lib/systemd/system/munin-node.service; enabled) Active: active (running) since Tue, 25 Sep 2012 14:19:45 +0100; 7s ago Docs: man:munin-node Process: 8014 ExecStart=/usr/sbin/munin-node (code=exited, status=0/SUCCESS) Main PID: 8015 (munin-node) CGroup: name=systemd:/system/munin-node.service â 8015 munin-node How reproducible: Steps to Reproduce: 1. Install munin-node on server and try to start it after configuring. 2. 3.
Status: NEW => ASSIGNEDAssignee: bugsquad => guillomovitch
Set to assigned in error.
Status: ASSIGNED => NEW
Will it work if you rename /usr/lib/tmpfiles.d/munin.conf -> /usr/lib/tmpfiles.d/munin-node.conf and reboot? Tho' i'm not 100% sure if munin itself needs this directory or not.
Keywords: (none) => NEEDINFOCC: (none) => sander.lepik
Created attachment 2857 [details] Proposed patch After discussion with Sander and Colin I have tested this patch and it fixes this bug.
One more thing i noticed. Is this section needed? %pre node %_pre_useradd %{name} %{_localstatedir}/lib/%{name} /bin/false munin-node requires common package that already adds user in its %pre.
It would seem not. I will do some testing with it removed ;)
Created attachment 2865 [details] Proposed patch Updated patch.
Attachment 2857 is obsolete: 0 => 1
The munin-node specific %pre section is indeed useless, but that's a secondary issue. That's a generic problem with tmpfiles configuration files that they are not honored immediatly at package installation time. I'd rather use a generic solution, such as a rpm file trigger, rather than a hack in munin package.
Hack? What makes it a hack?
It is a local workaround, not a generic solution to the problem.
This is not a local workaround, this is what Colin suggested on IRC and this is how systemd works with tmpfiles. I fail to see it as a hack :/
Any package relying on systemd-tpmfiles to create directories under tmpfs filesystems has exactly the same concern, munin has nothing special here. Hence the need for a general solution, such as a rpm filetrigger. I just commited systemd-193-2.mga3, fixing this issue.
Status: NEW => RESOLVEDResolution: (none) => FIXED