shorewall-users April 2012 archive
Main Archive Page > Month Archives  > shorewall-users archives
shorewall-users: Re: [Shorewall-users] Shorewall

Re: [Shorewall-users] Shorewall

From: Ed W <lists_at_nospam>
Date: Mon Apr 16 2012 - 00:54:16 GMT


>> 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?


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!
Shorewall-users mailing list