iptables-restore has some flags that could be useful: --verbose, --test (to prevent the actual sending back to the kernel), --noflush (to prevent flushing already existing chains) If that doesn't help at all, you could either use strace to find if it is hanging on a syscall, or add #define DEBUG to the top of iptables-restore.c and recompile to enable more debugging output. Are there rules on tables other than filter? Those aren't flushed by iptables -F and could possibly be slowing it down if there were many of them. Hope that helps, Daniel De Graaf On 3/5/07, Rackage | Randles <randles@xxxxxxxxxxx> wrote:
Hi, I recently noticed that one of my firewalls was taking a very long time to reboot. Which was odd as its a very new machine. On investigation is seemed to be the iptables-restore command that was adding 10+ minutes to the boot-up times. I ran iptables-restore from a terminal and found that it was indeed taking an amazingly long time. Obviously I assumed it was related to the rules on the server, so I flushed all rules and all user defined tables from the firewall (nat, mangle and filter) and used iptables-save which took less than 1 millisecond :) on the empty rule set. However iptables-restore is still taking 10+ minutes even with no rules to read / apply. Has anyone seen the behaviour before? or has anybody got some bright ideas on how I might continue debugging this issue? Thanks in Advance Regards Ben
