|Main Archive Page > Month Archives > shorewall-users archives|
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?
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
>>>> 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
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