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.1 Which 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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
