Hi,
sorry for late answer.
I have removed action.py patch and put
sleep ${RANDOM:0:1}.${RANDOM: -1:1}
onto first line of actionstart and actionstop
So I get more sleep values without big delay - it should be from 0.0 to 3.9, I
think
It seems to work nicely now
With regards
Libor
Dne čtvrtek 05 Listopad 2009 16:17:13 Yaroslav Halchenko napsal(a):
> oki doki... it is indeed the fact here -- whenever multiple
> processes/threads/whatever contact iptables in parallel
>
> $> for f in {1..5}; do cn=fail2ban-proftpd$f; echo $cn; /bin/sh -c
> "iptables -N $cn; iptables -A $cn -j RETURN; iptables -I INPUT -p tcp -m
> multiport --dports ftp,ftp-data,ftps,ftps-data -j $cn" ; done
> fail2ban-proftpd1
> fail2ban-proftpd2
> fail2ban-proftpd3
> fail2ban-proftpd4
> fail2ban-proftpd5
> $> for f in {1..5}; do cn=fail2ban-proftpd$f; echo $cn; iptables -D INPUT
> -p tcp -m multiport --dports ftp,ftp-data,ftps,ftps-data -j $cn; iptables
> -F $cn; iptables -X $cn; done fail2ban-proftpd1
> fail2ban-proftpd2
> fail2ban-proftpd3
> fail2ban-proftpd4
> fail2ban-proftpd5
>
> So -- everything was cool, lets try now start them in parallel:
>
> $> for f in {1..5}; do cn=fail2ban-proftpd$f; echo $cn; /bin/sh -c
> "iptables -N $cn; iptables -A $cn -j RETURN; iptables -I INPUT -p tcp -m
> multiport --dports ftp,ftp-data,ftps,ftps-data -j $cn" & ; done
> fail2ban-proftpd1
> [2] 7312
> fail2ban-proftpd2
> [3] 7314
> fail2ban-proftpd3
> [4] 7315
> fail2ban-proftpd4
> [5] 7322
> fail2ban-proftpd5
> iptables: Invalid argument. Run `dmesg' for more information.
> iptables: Resource temporarily unavailable.
> $>
> $> for f in {1..5}; do cn=fail2ban-proftpd$f; echo $cn; iptables -D INPUT
> -p tcp -m multiport --dports ftp,ftp-data,ftps,ftps-data -j $cn; iptables
> -F $cn; iptables -X $cn; done fail2ban-proftpd1
> fail2ban-proftpd2
> fail2ban-proftpd3
> iptables: No chain/target/match by that name.
> fail2ban-proftpd4
> fail2ban-proftpd5
>
> So, here we got it -- iptables might not digest nicely a bulk of requests
> done in parallel. Even if I set affinity for children tasks to run on the
> same core with taskset (so there could not be real parallelism) -- same
> shit.
>
> You get more fun if you go beyond 5 ;) (all those missing .so etc messages)
>
> BTW -- there were no further information in dmesg
>
> So, as a temporary solution I would just advise you to add arbitrary sleep
> time at the beginning of each chain initiation/shutdown(just in case),
> smth like:
>
> actionstart = sleep ${RANDOM:0:1}
> iptables -N fail2ban-<name>
> iptables -A fail2ban-<name> -j RETURN
> iptables -I INPUT -p <protocol> -m multiport --dports <port>
> -j fail2ban-<name>
>
> actionstop = sleep ${RANDOM:0:1}
> iptables -D INPUT -p <protocol> -m multiport --dports <port>
> -j fail2ban-<name> iptables -F fail2ban-<name>
> iptables -X fail2ban-<name>
>
>
> I guess average delay of 5 sec would be tolerable, right? ;)
> if you have "better sleep" then use 0.${RANDOM:0:1} ;-)
>
> On Thu, 05 Nov 2009, Libor Klepáč wrote:
> > Hi,
> > You are welcome.
> > Let's see if someone else can confirm this behaviour. Maybe they will
> > have other ideas.
>
signature.asc
Description: This is a digitally signed message part.
