Hi, >> Hmm, it's possible. I'm just debugging another problem where ipset >> takes some many seconds to run if reverse dns isn't available (eg >> iptables -P OUTPUT DROP), eg this takes some 10s of seconds in this >> state... (the change was I tried to lock down iptables at boot about the >> same time I updated shorewall, durr) > That's what Shorewall-init is for.
Noted. I scanned it quickly and it *appeared* to run the shorewall script? That takes some good few seconds on my small machine, hence I just knocked up a small script to run some iptables commands. Note I'm on gentoo and they have a very slightly different syntax for init, mainly it offers support for depencies, so I really need to go custom init script here anyway > So it takes 60 seconds to time out a stale lock. Seems so. Note I discovered a currently undocumented config param LOCKFILE which I used to move my lockfile to "/var/lock/shorewall.lock". My bootmisc script cleans this at startup (and the trend seems to be that this should become tmpfs on /run ?) and I think this way I can avoid stale locks on reboot. Any chance this param might become "official" or at least noted that you have one user now! >> I *think* however, I need to do some more testing. I believe that what >> I might be seeing is problems due to the ipset timeouts, this has >> triggered some reboots to gain control and that in turn may have caused >> me to see some lock timeouts. This indeed seems to be the main issue I am facing. Apologies for claiming a change in behaviour. As an aside, do you understand why there is a reverse dns lookup generated for my ipset create? (bitmap ip/mac). Unless networking is working then it takes 5 secs for each command to return... Instant when network is working.. I posted to the netfilter list already >> Let me just check that chain of logic. >> However, in any case, would it not be possible to check if there even is >> a PID with the number shown in the lock file and bail out immediately if >> not? This is a common algorithm (although I will concede it can get >> racy in corner cases) > That code is in place -- see mutex_on() in lib.base. OK, I am up against a deadline at the moment, but I will debug further as I can. I'm definitely NOT seeing that behaviour right now (might be config cockup?), but I definitely recall that behaviour in the past - if you recall you kindly made it work this way as a result of my previous winging about slow timeouts! Can you confirm if a config mistake could cause it to sit and wait for the timeout rather than checking for an alive pid? Thanks Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
