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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
