2

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.

  • 1
    This looks like a bug from a really old version of fail2ban that was fixed years ago. – Michael Hampton Sep 28 '16 at 3:38
  • @Michael Hamption, can you elaborate on the specific bug? – ArsTropica Sep 28 '16 at 15:47
  • Current version of fail2ban is v0.8.11. – ArsTropica Sep 28 '16 at 15:55
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.

| improve this answer | |
  • 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
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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.