Description of problem: Iptables is failing to start on fedora 19. when iptables start it's trying to touch /var/lock/subsys/iptables it is failing because the directory /var/lock/subsys does not exist on fedora19 [root@tigris04 ~]# systemctl start iptables.service Job for iptables.service failed. See 'systemctl status iptables.service' and 'journalctl -xn' for details. [root@tigris04 ~]# systemctl status iptables.service iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled) Active: failed (Result: exit-code) since Sun 2013-07-21 15:10:26 IDT; 4s ago Process: 15012 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=1/FAILURE) Jul 21 15:10:26 tigris04.scl.lab.tlv.redhat.com iptables.init[15012]: iptables: Applying firewall rules: [ OK ] Jul 21 15:10:26 tigris04.scl.lab.tlv.redhat.com iptables.init[15012]: touch: cannot touch ‘/var/lock/subsys/iptables’: No such file or directory Jul 21 15:10:26 tigris04.scl.lab.tlv.redhat.com systemd[1]: iptables.service: main process exited, code=exited, status=1/FAILURE Jul 21 15:10:26 tigris04.scl.lab.tlv.redhat.com systemd[1]: Failed to start IPv4 firewall with iptables. Jul 21 15:10:26 tigris04.scl.lab.tlv.redhat.com systemd[1]: Unit iptables.service entered failed state.
(In reply to Ohad Basan from comment #0) > the directory /var/lock/subsys does not exist on fedora19 AFAIK it should be recreated on boot per tmpfiles.d configuration file /usr/lib/tmpfiles.d/legacy.conf If it's not, then it's most likely a systemd bug. # rpm -qf /usr/lib/tmpfiles.d/legacy.conf systemd-204-9.fc19.x86_64
I can confirm, I'm hitting this too on F19: $ uname -r ; rpm -q systemd iptables 3.9.5-301.fc19.x86_64 systemd-204-9.fc19.x86_64 iptables-1.4.18-1.fc19.x86_64 $ systemctl status iptables iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled) Active: failed (Result: exit-code) since Wed 2013-07-31 04:31:23 EDT; 6s ago Process: 17338 ExecStart=/usr/libexec/iptables/iptables.init start (code=exited, status=1/FAILURE) Jul 31 04:31:23 meadow-compute iptables.init[17338]: iptables: Applying firewall rules: [ OK ] Jul 31 04:31:23 meadow-compute iptables.init[17338]: touch: cannot touch ‘/var/lock/subsys/iptables’: No such file or directory Jul 31 04:31:23 meadow-compute systemd[1]: iptables.service: main process exited, code=exited, status=1/FAILURE Jul 31 04:31:23 meadow-compute systemd[1]: Failed to start IPv4 firewall with iptables. Jul 31 04:31:23 meadow-compute systemd[1]: Unit iptables.service entered failed state.
It works for me. As I said above if the cause is missing /var/lock/subsys/ then it's most likely a systemd bug.
Is your /var/lock a symlink to ../run/lock? Is your /var a distinct mount from / ?
Closing due to lack of response.
Before you go closing due to lack of response you should actually try and do some work! I am having the same problem on FC20. You say it's a systemd bug. You offered no fix, no solution, nothing. Are you serious? So how come you didn't fix it on fc19? How come you let it get to fc20? /var is a mount of a different lvm volume in my system. As a professional system should be. /var/lock is not a symlink to ../run/lock. Additionally, if you try to manually create the folder, it says it has been created but if you do an ls -l /var/lock/subsys you get nothing. The folder isn't really there. Let me know if you'd like to see some strace output of the mkdir /var/lock/subsys.
Can you 1. post your /etc/fstab 2. show the output of ls -l /var/lock /var/lock/subsys /var/lock/subsys/
(In reply to clonnerz from comment #6) > /var/lock is not a symlink to ../run/lock. Perhaps it was not converted properly when upgrading from earlier Fedora releases, but it really should be a symlink on all current installations. Please make it so. > Additionally, if you try to manually create the folder, it says it has been > created but if you do an ls -l /var/lock/subsys you get nothing. The folder > isn't really there. "ls -l /var/lock/subsys" lists the *contents* of the directory. If you want to see the directory itself, you need to add "-d".
This problem still exists on fedora-21 beta. Does it need to be marked as a security bug before we see any action?
(In reply to Wolfgang Rupprecht from comment #10) > This problem still exists on fedora-21 beta. New install or upgrade? > Does it need to be marked as a security bug before we see any action? Providing the requested information would be more effective.
(In reply to Wolfgang Rupprecht from comment #10) > This problem still exists on fedora-21 beta. Please retry with "enforcing=0" on the kernel command line. I suspect a bug in the SELinux labelling code that has been introduced recently. (I.e. the bug affecting Fedora 21 is a different bug than what was discussed in this BZ.)
The labelling bug should be now fixed upstream by: http://cgit.freedesktop.org/systemd/systemd/commit /?id=2d58aa4692e9fc47911bff5d064ba3e328c35369
(In reply to Michal Schmidt from comment #12) > Please retry with "enforcing=0" on the kernel command line. > I suspect a bug in the SELinux labelling code that has been introduced > recently. Good call. enforcing=0 does indeed fix it.
kmod-18-4.fc21, systemd-216-11.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2014-14307/kmod-18-4.fc21,systemd-216-11.fc21
Package kmod-18-4.fc21, systemd-216-11.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kmod-18-4.fc21 systemd-216-11.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14307/kmod-18-4.fc21,systemd-216-11.fc21 then log in and leave karma (feedback).
kmod-18-4.fc21, systemd-216-11.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.