|Main Archive Page > Month Archives > shorewall-users archives|
>> 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?
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!
Shorewall-users mailing list