Bug 986667 - IPtables is broken on f19 > no /var/lock/subsys/
IPtables is broken on f19 > no /var/lock/subsys/
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-21 08:20 EDT by Ohad Basan
Modified: 2014-11-11 21:38 EST (History)
16 users (show)

See Also:
Fixed In Version: kmod-18-4.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-11 21:38:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ohad Basan 2013-07-21 08:20:15 EDT
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.
Comment 1 Jiri Popelka 2013-07-22 05:27:56 EDT
(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
Comment 2 Kashyap Chamarthy 2013-07-31 04:41:11 EDT
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.
Comment 3 Jiri Popelka 2013-07-31 06:55:47 EDT
It works for me.
As I said above if the cause is missing /var/lock/subsys/ then it's most likely a systemd bug.
Comment 4 Michal Schmidt 2013-07-31 07:00:10 EDT
Is your /var/lock a symlink to ../run/lock?
Is your /var a distinct mount from / ?
Comment 5 Lennart Poettering 2014-02-23 11:47:23 EST
Closing due to lack of response.
Comment 6 clonnerz 2014-07-02 09:22:11 EDT
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.
Comment 7 Zbigniew Jędrzejewski-Szmek 2014-07-02 09:35:21 EDT
Can you

1. post your /etc/fstab

2. show the output of ls -l /var/lock /var/lock/subsys /var/lock/subsys/
Comment 8 Michal Schmidt 2014-07-02 10:46:32 EDT
(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".
Comment 10 Wolfgang Rupprecht 2014-11-06 05:37:53 EST
This problem still exists on fedora-21 beta.  Does it need to be marked as a security bug before we see any action?
Comment 11 Michal Schmidt 2014-11-06 10:05:18 EST
(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.
Comment 12 Michal Schmidt 2014-11-06 10:54:52 EST
(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.)
Comment 13 Michal Schmidt 2014-11-06 11:03:39 EST
The labelling bug should be now fixed upstream by:

http://cgit.freedesktop.org/systemd/systemd/commit
/?id=2d58aa4692e9fc47911bff5d064ba3e328c35369
Comment 14 Wolfgang Rupprecht 2014-11-06 14:15:54 EST
(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.
Comment 15 Fedora Update System 2014-11-06 19:36:27 EST
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
Comment 16 Fedora Update System 2014-11-07 00:32:26 EST
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).
Comment 17 Fedora Update System 2014-11-11 21:38:31 EST
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.

Note You need to log in before you can comment on or make changes to this bug.