The solution to the error “Another app is currently holding the xtables lock”

Recently noticed on one server with the billing system ABillS, that when the script /etc/ppp/ip-up is executed in bulk, an error occurs:

Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Having looked at the script code, I found that there are two rules among the iptables rules that can slow down the work, namely, the search for ipoe interfaces by two commands:

IPTABLES="/sbin/iptables"
EXIST=`${IPTABLES} -t nat -L PREROUTING -v | grep "${IFNAME} ";  ${IPTABLES} -L -v | grep DROP | grep "${IFNAME} "`

To raise 3000 sessions, it took more than 30 minutes and some rules could not be added at all or deleted by the script.
By default, if the -L option is used, iptables resolves the IP addresses and tries to display DNS names instead of them, which takes a long time, and so that this does not happen, you need to add the -n option, and just in case I added the -w 20 switch, which will cause the new rules to be postponed until 20 seconds if iptables is already busy executing another command:

IPTABLES="/sbin/iptables"
IPTABLES_WAIT="-w 20"
EXIST=`${IPTABLES} $IPTABLES_WAIT -t nat -n -L PREROUTING -v | grep "${IFNAME} ";  ${IPTABLES} $IPTABLES_WAIT -n -L -v | grep DROP | grep "${IFNAME} "`

After that, the script with iptables rules began to work out instantly.
Since the old rules are not all fulfilled, I checked this by counting some by the team:

iptables -n -L -t nat -v | grep DNAT | wc -l

And I checked with the number of sessions, the rules were obviously smaller, so I had to clear all rules and restart the session so that the /etc/ppp/ip-up script worked correctly, this time at 3000 sessions it did its job in less than a minute.
Note that in the / etc / ppp / scripts, it’s better not to use iptables rules.

Did my article help you? How about buying me a cup of coffee as an encouragement? Buy me a coffe.

Leave a comment

Leave a Reply