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

Re: [Shorewall-users] Shorewall

From: Tom Eastep <teastep_at_nospam>
Date: Mon Apr 16 2012 - 00:11:56 GMT

On 4/15/12 4:42 PM, Ed W wrote:
> On 15/04/2012 23:53, Tom Eastep wrote:
>>> I'm seeing a regression in stale lock handling. If there is a stale
>>> lock at boot is seems to deadlock forever (which is inconvenient...).
>>> If I start it via the command line it seems to time out after some large
>>> number of seconds and continue. Old behaviour ( was to somehow
>>> immediately burst the lock if it was stale.
>> Lock handling hasn't changed in years; so what you are seeing must be a
>> side effect of something else.
> 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.

> ipset create cp1 bitmap:ip,mac range
>> What are your settings for:
> 60

So it takes 60 seconds to time out a stale lock.
> /var/lock/subsys/shorewall

That file really isn't a lock file; it simply exists when Shorewall is
started and removed when shorewall is Stopped.

> However, the message I get says something about "stale lock on
> /var/lib/shorewall/lock", so I think it's something different?
>> What are the contents of your shorewallrc file (normally
>> /usr/share/shorewall/shorewallrc)?
> HOST=linux
> PREFIX=/usr
> SHAREDIR=/usr/share
> PERLLIBDIR=${PREFIX}/share/shorewall
> CONFDIR=/etc
> SBINDIR=/sbin
> MANDIR=/usr/share/man
> INITDIR=etc/init.d
> VARDIR=/var/lib
> Can you confirm this looks sensible? (Gentoo based system, setting
> host=linux to build).

Looks reasonable.

> However, I'm sure you made a change for me some few versions back where
> the lock file handling got smarter, I had assumed you checked for a pid
> listed by the lock file? What I'm seeing now (but perhaps it's the same
> for is that lock timeout is quite some time (presume 60 seconds...)

That's your MUTEX_TIMEOUT setting, yet.

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

-- 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 \________________________________________________

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