3

I manage an Ubuntu server (14.04) with ispconfig 3 installed on it. The server is being used for mail, web and data. The sysadmin before me had fail2ban and ufw enabled but we have been experiencing issues with dovecot authentication all day today. When I tried to access the firewall, I kept getting the error message:

ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Trying a soft reboot froze the server, and a hard reboot brought the problem right back.

Then, upon further investigation using lsof -p $(pidof iptables), I get the following output:

COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF    NODE NAME
iptables 1526 root  cwd    DIR                9,1     4096       2 /
iptables 1526 root  rtd    DIR                9,1     4096       2 /
iptables 1526 root  txt    REG                9,1    87768  261694 /sbin/xtables-multi
iptables 1526 root  mem    REG                9,1     6336 1180648 /lib/xtables/libxt_standard.so
iptables 1526 root  mem    REG                9,1    14664 1180071 /lib/x86_64-linux-gnu/libdl-2.19.so
iptables 1526 root  mem    REG                9,1  1840928 1180085 /lib/x86_64-linux-gnu/libc-2.19.so
iptables 1526 root  mem    REG                9,1    47712 1181161 /lib/libxtables.so.10.0.0
iptables 1526 root  mem    REG                9,1    31520 1179359 /lib/libip6tc.so.0.1.0
iptables 1526 root  mem    REG                9,1    27392 1179360 /lib/libip4tc.so.0.1.0
iptables 1526 root  mem    REG                9,1   149120 1180078 /lib/x86_64-linux-gnu/ld-2.19.so
iptables 1526 root    0r  FIFO                0,8      0t0   21609 pipe
iptables 1526 root    1u   CHR                1,3      0t0    1029 /dev/null
iptables 1526 root    2u   CHR                1,3      0t0    1029 /dev/null
iptables 1526 root    3u  unix 0xffff880190eabb80      0t0  686890 @xtables
iptables 1526 root    4u   raw                         0t0  686891 00000000:00FF->00000000:0000 st=07
iptables 1526 root    5w   REG                9,1   242173  917201 /var/log/fail2ban.log
iptables 1526 root    6r  0000                0,9        0    7704 anon_inode
iptables 1526 root    7r  0000                0,9        0    7704 anon_inode
iptables 1526 root    8r  0000                0,9        0    7704 anon_inode
iptables 1526 root    9r  FIFO                0,8      0t0   20579 pipe
iptables 1526 root   10w  FIFO                0,8      0t0   20579 pipe

Any pointers on what is locking xtables and how best to resolve will be welcome.

techraf
  • 4,243
  • 8
  • 29
  • 44
ArsTropica
  • 131
  • 1
  • 1
  • 4

4 Answers4

2

This answer suggests the possibility of delays caused by slow DNS lookups, which can be avoided by including -n in the iptables command line. Perhaps you can use strace or ltrace to investigate what the active iptables process is doing (pid 1526 in your output), or at least check, via something like ps -fp $(pidof iptables), whether the iptables command includes -n.

Community
  • 1
Eirik Fuller
  • 139
  • 2
  • Erik, Thanks for your reply. Would the slow DNS account for the server freezing and the dovecot authentication failures? – ArsTropica Sep 27 '16 at 22:10
  • It seems plausible that a single problem (DNS sluggishness) might have multiple symptoms. The dovecot problems might be directly related to DNS; it seems the iptables issue is more about disruption of diagnosis efforts than a likely cause of dovecot problems. At this point a DNS issue is mere speculation, but it might make sense to at least rule it out. – Eirik Fuller Sep 27 '16 at 22:15
  • When I ran into this problem, it was with a script with loads of iptables commands, but all on IP addresses, no DNS involved. – Mantriur Feb 22 '21 at 16:52
0

First, you need to type a command on your server #lsof -n 2>/dev/null | grep /run/xtables.lock then delete file /run/xtables.lock by using rm -f /run/xtables.lock

Prem Patil
  • 1
  • 1
0

Found this problem in Ubuntu 22.04 with Webmin 2.013 having both IPv4 and IPv6 rules configured for activation at boot.

The service webmin-ip6tables (for IPv6) where locking the xtables.lock file and simultaneously the service webmin-iptables (for IPv4) were trying to load its ruleset and so getting blocked (I used systemctl status webmin-iptables and systemctl status webmin-ip6tables to check that).

Solution: Edited the service for IPv6 in the file webmin-ip6tables.service under /etc/systemd/system/multi-user.target.wants/ to add a five second delay in the line ExecStart, resulting in:

[Unit] Description=Load ip6tables save file

[Service] ExecStart=/bin/sh -c 'sleep 5; /sbin/ip6tables-legacy-restore </etc/webmin/firewall6/ip6tables.save' ExecStop=/sbin/ip6tables -t filter -F ; /sbin/ip6tables -t nat -F ; /sbin/ip6tables -t mangle -F ; /sbin/ip6tables -t filter -P INPUT ACCEPT ; /sbin/ip6tables -t filter -P OUTPUT ACCEPT ; /sbin/ip6tables -t filter -P FORWARD ACCEPT ; /sbin/ip6tables -t nat -P PREROUTING ACCEPT ; /sbin/ip6tables -t nat -P POSTROUTING ACCEPT ; /sbin/ip6tables -t nat -P OUTPUT ACCEPT ; /sbin/ip6tables -t mangle -P PREROUTING ACCEPT ; /sbin/ip6tables -t mangle -P OUTPUT ACCEPT Type=oneshot RemainAfterExit=yes

[Install] WantedBy=multi-user.target

Unfortunately, I found that delays in the Webmin firewall configuration don't apply to the boot actions, so I couldn't solve it there.

This change makes the IPv6 ruleset loading wait 5 seconds, giving enough time to the IPv4 ruleset to be loaded successfully.

Caveat: If the activation of rules at boot in Webmin is disabled and then enabled again, the service file could be overwritten, but there is no reason to do the disabling/enabling cycle after configuration, only modifiying the rulesets and apply changes.

Fjor
  • 196
  • 5
0

I encountered that same problem with a long script of iptables commands. It happened rather randomly and varied between systems. I'm suspecting a race condition.

For that case, the error message provided its own solution: Using the -w flag will cause iptables to wait for the lock to become available instead of failing.

When not using iptables directly but a management software, that software will have to be patched accordingly. Obviously there is a risk of iptables hanging indefinitely if something caused the lock to become stale.

Mantriur
  • 379
  • 2
  • 13