On 04/15/2012 05:54 PM, Ed W wrote: > 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?
Yes -- it run's the compiled script's 'stop' command. > That takes some good few seconds on my small machine, hence I just > knocked up a small script to run some iptables commands. Which shell do you use? Not Bash, I hope. And about your iptables commands -- setting the OUTPUT policy to DROP will block intra-system connections via the loopback device, once it is brought up. > 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! It seems to have been dropped at some point; not intentional, so I'll resurrect it. > >>> 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 > You aren't using LDAP authentication, are you? > >>> 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? I cannot. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
