Я управляю сервером Ubuntu (14.04) с установленным на нем ispconfig 3. Сервер используется для почты, Интернета и данных. У системного администратора до меня были включены fail2ban и ufw, но сегодня мы испытывали проблемы с аутентификацией dovecot. Когда я пытался получить доступ к брандмауэру, я продолжал получать сообщение об ошибке:
ОШИБКА: проблема с запуском iptables: другое приложение в настоящее время удерживает блокировку xtables. Возможно, вы хотите использовать параметр -w?
Попытка мягкой перезагрузки заморозила сервер, а жесткая перезагрузка вернула проблему.
Затем при дальнейшем исследовании с использованием lsof -p $(pidof iptables), Я получаю следующий результат:
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
Любые указатели на то, что блокирует xtables и как лучше всего разрешить, будут приветствоваться.
Этот ответ предполагает возможность задержек, вызванных медленным поиском DNS, которых можно избежать, включив -n в iptables командная строка. Возможно, вы можете использовать strace или ltrace исследовать, что активный iptables процесс выполняет (pid 1526 в вашем выводе) или, по крайней мере, проверяет, через что-то вроде ps -fp $(pidof iptables), будь то iptables команда включает -n.
Я столкнулся с той же проблемой с длинным скриптом команд iptables. Это произошло довольно случайно и варьировалось между системами. Я подозреваю состояние гонки.
В этом случае сообщение об ошибке предлагает собственное решение: использование флага -w заставит iptables вместо сбоя ждать, пока блокировка станет доступной.
Если iptables используется не напрямую, а через программное обеспечение для управления, это программное обеспечение необходимо соответствующим образом исправить. Очевидно, существует риск зависания iptables на неопределенный срок, если что-то привело к устареванию блокировки.