|Main Archive Page > Month Archives > shorewall-users archives|
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
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
>> 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 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.
Shorewall-users mailing list