Early adopters of 4.5.2.1 have found a couple of serious problems, so
I''ve uploaded 4.5.2.2 which corrects them.
1) If a shorewallrc file is passed to the 4.5.2.1 Shorewall-core
install.sh, subsequent compilations fail. The error message
indicates that the compiler is looking for lib.core, but the
pathname has embedded spaces.
2) The 4.5.2.1 Shorewall/Shorewall6 installer installs an incorrect
file as /etc/shorewall[6]/Makefile.
Thank you for using Shorewall.
-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 \________________________________________________
------------------------------------------------------------------------------
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
On 14/04/2012 21:30, Tom Eastep wrote:> Early adopters of 4.5.2.1 have found a couple of serious problems, so > I''ve uploaded 4.5.2.2 which corrects them. > > 1) If a shorewallrc file is passed to the 4.5.2.1 Shorewall-core > install.sh, subsequent compilations fail. The error message > indicates that the compiler is looking for lib.core, but the > pathname has embedded spaces. > > 2) The 4.5.2.1 Shorewall/Shorewall6 installer installs an incorrect > file as /etc/shorewall[6]/Makefile. > > Thank you for using Shorewall. >On shorewall-core/configure:134 are these lines: elif [ $vendor = linux ]; then rcfile=$shorewallrc.default; Should that be $shorewallrc or just shorewallrc? I''m getting an installation error, "can''t find .default" when using vendor=linux? 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
On 15/04/2012 19:45, Ed W wrote:> On 14/04/2012 21:30, Tom Eastep wrote: >> Early adopters of 4.5.2.1 have found a couple of serious problems, so >> I''ve uploaded 4.5.2.2 which corrects them. >> >> 1) If a shorewallrc file is passed to the 4.5.2.1 Shorewall-core >> install.sh, subsequent compilations fail. The error message >> indicates that the compiler is looking for lib.core, but the >> pathname has embedded spaces. >> >> 2) The 4.5.2.1 Shorewall/Shorewall6 installer installs an incorrect >> file as /etc/shorewall[6]/Makefile. >> >> Thank you for using Shorewall. >> > On shorewall-core/configure:134 are these lines: > elif [ $vendor = linux ]; then > rcfile=$shorewallrc.default; > > Should that be $shorewallrc or just shorewallrc? > > I''m getting an installation error, "can''t find .default" when using > vendor=linux? >I''m finding a bunch of problems actually. Could you please try installing with vendor=linux to repro. I get: ./configure --prefix=/usr --build=i486-gentoo-linux-uclibc --host=linux --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib INFO: Creating a generic Linux installation - Sun Apr 15 20:16:38 BST 2012 ./configure: line 162: [: too many arguments Then installing shorewall-4.5.2.2 on gentoo I see: >>> Install shorewall-4.5.2.2 into /var/tmp/portage/net-firewall/shorewall-4.5.2.2/image/ category net-firewall Perl/compiler.pl syntax OK Installing Shorewall Version 4.5.2.2 ACCESS DENIED unlink: /sbin/shorewall install: cannot remove `/sbin/shorewall'': Permission denied ERROR: Failed to install -T -o root -g root -m 0755 shorewall /sbin/shorewall * ERROR: net-firewall/shorewall-4.5.2.2 failed (install phase): * install.sh failed The line which generates this error is: PREFIX="${D}" HOST="linux" ./install.sh || die "install.sh failed" 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
On 15/04/2012 20:21, Ed W wrote:> Then installing shorewall-4.5.2.2 on gentoo I see: > > > >>> Install shorewall-4.5.2.2 into > /var/tmp/portage/net-firewall/shorewall-4.5.2.2/image/ category net-firewall > Perl/compiler.pl syntax OK > Installing Shorewall Version 4.5.2.2 > ACCESS DENIED unlink: /sbin/shorewall > install: cannot remove `/sbin/shorewall'': Permission denied >OK, cancel this one. I see that PREFIX has been replaced by DESTDIR... Probably I should read the release notes? Sorry 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
On 14/04/2012 21:30, Tom Eastep wrote:> Early adopters of 4.5.2.1 have found a couple of serious problems, so > I''ve uploaded 4.5.2.2 which corrects them. > >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 (4.5.1.1) was to somehow immediately burst the lock if it was stale. 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
On 4/15/12 1:59 PM, Ed W wrote:> On 14/04/2012 21:30, Tom Eastep wrote: >> Early adopters of 4.5.2.1 have found a couple of serious problems, so >> I''ve uploaded 4.5.2.2 which corrects them. >> >> > > 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 (4.5.1.1) 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. What are your settings for: MUTEX_TIMEOUT SUBSYSLOCK What are the contents of your shorewallrc file (normally /usr/share/shorewall/shorewallrc)? -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 \________________________________________________ ------------------------------------------------------------------------------ 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
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 (4.5.1.1) 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) ipset create cp1 bitmap:ip,mac range 192.168.111.0/24> What are your settings for: > > MUTEX_TIMEOUT60> SUBSYSLOCK/var/lock/subsys/shorewall 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 LIBEXECDIR=${PREFIX}/share PERLLIBDIR=${PREFIX}/share/shorewall CONFDIR=/etc SBINDIR=/sbin MANDIR=/usr/share/man INITDIR=etc/init.d INITSOURCE=init.sh INITFILE=$PRODUCT AUXINITSOURCEAUXINITFILESYSTEMDSYSCONFFILESYSCONFDIRANNOTATEDVARDIR=/var/lib Can you confirm this looks sensible? (Gentoo based system, setting host=linux to build). 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 4.5.1.1) is that lock timeout is quite some time (presume 60 seconds...) 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) Thanks for replying 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
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 (4.5.1.1) 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 192.168.111.0/24 > > > >> What are your settings for: >> >> MUTEX_TIMEOUT > 60So it takes 60 seconds to time out a stale lock.> > >> SUBSYSLOCK > /var/lock/subsys/shorewallThat 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 > LIBEXECDIR=${PREFIX}/share > PERLLIBDIR=${PREFIX}/share/shorewall > CONFDIR=/etc > SBINDIR=/sbin > MANDIR=/usr/share/man > INITDIR=etc/init.d > INITSOURCE=init.sh > INITFILE=$PRODUCT > AUXINITSOURCE> AUXINITFILE> SYSTEMD> SYSCONFFILE> SYSCONFDIR> ANNOTATED> 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 4.5.1.1) 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 -- 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 \________________________________________________ ------------------------------------------------------------------------------ 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
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
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 \________________________________________________ ------------------------------------------------------------------------------ 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
Hi, thanks for the reply>> 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.Busybox ash. Processor is a 500mhz Geode on a PC Engines Alix board. It takes 1-2 seconds to startup a non trivial perl script, seems like module loading is what slows it down. This seems inline with my desktop machine which takes around 100ms for a similar script and in general I see about a 10x difference in performance between the two machines. However, quite possibly I have bolloxed my perl install - happy to be told I''m an idiot?> 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.I knew there was a reason to use your clever scripts. Good catch - thanks for pointing that out>> 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?Oh no! Actually I have traced the issue to a uclibc problem with getaddrinfo causing excessive dns lookups - if your resolver isn''t working then this causes very long delays on trivial commands. I have sent a patch to the uclibc list which I think has been accepted, but it may be worth being aware of for the next 12 months+ that there is such a fault with uclibc < 0.9.33.1>>>> 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.OK, I will come back to this in the near future, but I can trivially reproduce this by running say "shorewall restart", hit control c part way through, then run the command again and it sits there for a bunch of time waiting on the lock. Remember busybox+uclibc, so quite possibly some bug due to those. I will debug further once I get a touch more capacity Thanks for all your very helpful answers Ed W ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
On 04/18/2012 04:03 AM, Ed W wrote:> Hi, thanks for the reply > > >>> 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. > > Busybox ash. Processor is a 500mhz Geode on a PC Engines Alix board. > It takes 1-2 seconds to startup a non trivial perl script, seems > like module loading is what slows it down.You don''t have module autoloading in your kernel? What is the setting for LOAD_HELPERS_ONLY? Incidentally, Shorewall-init does not run Perl in any circumstance.> This seems inline with my desktop machine which takes around 100ms > for a similar script and in general I see about a 10x difference in > performance between the two machines. However, quite possibly I have > bolloxed my perl install - happy to be told I''m an idiot? > > >> 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. > > I knew there was a reason to use your clever scripts. Good catch - > thanks for pointing that out > > >>> 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? > > Oh no! > > Actually I have traced the issue to a uclibc problem with getaddrinfo > causing excessive dns lookups - if your resolver isn''t working then > this causes very long delays on trivial commands. I have sent a > patch to the uclibc list which I think has been accepted, but it may > be worth being aware of for the next 12 months+ that there is such a > fault with uclibc < 0.9.33.1Which was no doubt exacerbated by your OUTPUT -P DROP because packets were being dropped before a ''no route to host'' ICMP could be generated.> > > >>>>> 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. > > OK, I will come back to this in the near future, but I can trivially > reproduce this by running say "shorewall restart", hit control c > part way through, then run the command again and it sits there for a > bunch of time waiting on the lock. Remember busybox+uclibc, so quite > possibly some bug due to those.I''ll play with it too. -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 \________________________________________________ ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
On 04/18/2012 06:46 AM, Tom Eastep wrote:> On 04/18/2012 04:03 AM, Ed W wrote: >>>> 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. >> >> OK, I will come back to this in the near future, but I can trivially >> reproduce this by running say "shorewall restart", hit control c >> part way through, then run the command again and it sits there for a >> bunch of time waiting on the lock. Remember busybox+uclibc, so quite >> possibly some bug due to those. > > I''ll play with it too.Here''s an experiment that I ran: root@gateway:~# shorewall version 4.5.2.2 root@gateway:~# shorewall restart Compiling... Processing /etc/shorewall/params ... ... Shorewall configuration compiled to /var/lib/shorewall/.restart Restarting Shorewall.... Initializing... Processing /etc/shorewall/init ... Processing /etc/shorewall/tcclear ... ^C root@gateway:~# ^C root@gateway:~# cat /var/lib/shorewall/lock 21942 root@gateway:~# shorewall restart Compiling... Processing /etc/shorewall/params ... ... Shorewall configuration compiled to /var/lib/shorewall/.restart WARNING: Stale lockfile /var/lib/shorewall/lock from pid 21942 removed Shorewall is not running Starting Shorewall.... Initializing... ... On this system, /bin/sh is Dash 0.5.5.1-7.4. Seems to work as expected. -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 \________________________________________________ ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
On 04/18/2012 07:07 AM, Tom Eastep wrote:> > Here''s an experiment that I ran: > > root@gateway:~# shorewall version > 4.5.2.2 > root@gateway:~# shorewall restart > Compiling... > Processing /etc/shorewall/params ... > ... > Shorewall configuration compiled to /var/lib/shorewall/.restart > Restarting Shorewall.... > Initializing... > Processing /etc/shorewall/init ... > Processing /etc/shorewall/tcclear ... > ^C > root@gateway:~# ^C > root@gateway:~# cat /var/lib/shorewall/lock > 21942 > root@gateway:~# shorewall restart > Compiling... > Processing /etc/shorewall/params ... > ... > Shorewall configuration compiled to /var/lib/shorewall/.restart > WARNING: Stale lockfile /var/lib/shorewall/lock from pid 21942 removed > Shorewall is not running > Starting Shorewall.... > Initializing... > ... > > On this system, /bin/sh is Dash 0.5.5.1-7.4. Seems to work as expected. >This is with Busybox Ash 1:1.17.1-8. root@gateway:~# cat /var/lib/shorewall/lock 24287 root@gateway:~# shorewall restart WARNING: Stale lockfile /var/lib/shorewall/lock from pid 24287 removed Shorewall is not running Starting Shorewall.... Initializing... -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 \________________________________________________ ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
On 18/04/2012 14:46, Tom Eastep wrote:> You don''t have module autoloading in your kernel? What is the setting > for LOAD_HELPERS_ONLY? >That in itself is a whole email thread on uclibc/netfilter if you scan for emails from me (not that interesting though). There are some nice patches in recent netfilter and some rotting patches in uclibc that I don''t think will get into mainstream. Upshot is that I have spent quite some time optimising this... Sincerely thanks for the thoughts though! I will benchmark it some more after I get my release out. It''s not so bad, but binaries are slow to load (flash drive with squashfs) and the processor is fairly limited. Busybox ash in use + uclibc + various gcc hardening options root@redbox $ time shorewall stop Stopping Shorewall.... Processing /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... Running /sbin/iptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/stopped ... done. real 0m 0.81s user 0m 0.33s sys 0m 0.26s root@redbox $ time shorewall stop Stopping Shorewall.... Processing /etc/shorewall/stop ... Processing /etc/shorewall/tcclear ... Running /sbin/iptables-restore... IPv4 Forwarding Enabled Processing /etc/shorewall/stopped ... done. real 0m 0.82s user 0m 0.32s sys 0m 0.25s root@redbox $ Test of stale pids: root@redbox $ shorewall start Starting Shorewall.... Device "wlan1" does not exist. Cannot find device "wlan1" Device "eth3" does not exist. Cannot find device "eth3" Device "wlan2" does not exist. Cannot find device "wlan2" Device "wlan3" does not exist. Cannot find device "wlan3" ^C root@redbox $ time shorewall start Giving up on lock file /var/lock/shorewall.lock Starting Shorewall.... ... snip ... Processing /etc/shorewall/start ... Processing /etc/shorewall/started ... done. real 0m 33.85s user 0m 1.06s sys 0m 1.26s My timeout (forgotten the var name) is set to 30 seconds, down from the default 60 secs Please don''t investigate further, its obviously something in my config. I will debug it and revert with the reason Many thanks! Ed W ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev