Starting WireGuard VPN... Can't lock /run/xtables.lock: Resource temporarily unavailable

hjkl · 8 February 2026 22:41

I am searching for an elegant solution to Can’t lock /run/xtables.lock: Resource temporarily unavailable generated by Wireguard startup script /etc/rc.d/rc3.d/S50wireguard

The box uses PPoE connection and, my ISP PPP server is a bit slow: I tested the “speed” of PPPD and is usually 8-12 seconds. The firewall contains a large list of blocking rules: all inbound traffic is blocked unless it comes from my country, and all outbound traffic is also blocked unless IP belongs to a few countries (US and some EU countries) - so FW needs some seconds to load/reload.

 iptables -S | wc
   2333   40583  283293

Therefore, after /etc/rc.d/rc3.d/S20network → ../init.d/network starts the connection daemon, the PPP finally gets an IP address after 8-10 seconds

During this time, all of these start:
/etc/rc.d/rc3.d/S30dhcp → ../init.d/dhcp

/etc/rc.d/rc3.d/S45guardian → /etc/rc.d/init.d/guardian

/etc/rc.d/rc3.d/S50openvpn-rw → ../init.d/openvpn-rw

and finally /etc/rc.d/rc3.d/S50wireguard → ../init.d/wireguard

When PPPD finally finished its negotiation with ISP it then triggers red.up

Both red.up and ../init.d/wireguard do contain some firewall manipulation which collide:

Starting Apache daemon...
Starting fcron...
Starting Guardian...
Starting OpenVPN Roadwarrior Server...
Starting OpenVPN Authenticator...
Starting WireGuard VPN...
Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
OpenVPN N2N connection 'Black2Grey' is not enabled [ WARNING ]
Starting apcupsd daemon...

IPFire v2.29 - www.ipfire.org
==============================
black-x86-64.go.ro running on Linux 6.12.41-ipfire x86_64
black-x86-64 login:

Because PPPD needs a variable amount of time to get from ISP the connection, IP address, Gateway and DNS, sometimes the message Can’t lock /run/xtables.lock: Resource temporarily unavailable is displayed for each of Starting Guardian... and
Starting OpenVPN Roadwarrior Server....

This part was solved by delaying the execution of S30dhcp, S50openvpn-rw, and S50openvpn-rw until PPPD gets an IP address:

/etc/rc.d/rc3.d/S25wait-for-ppp → ../init.d/wait-for-ppp I added a check for ppp0 IP address and if that is not present the script waits one second so this ensures that none of S30-S50 startup scripts starts during the PPPD negotiation

But!

Even if S50wireguard starts after PPD finishes (gets its IP address) it collides with red.up sequence

Result: several chains are empty

[root@black-x86-64 ~]# iptables -S | grep -E 'DHCPBLUEINPUT|WGINPUT|OVPNINPUTRW'
-N DHCPBLUEINPUT
-N OVPNINPUTRW
-N WGINPUT
-A INPUT -i blue0 -j DHCPBLUEINPUT
-A INPUT -j WGINPUT
-A INPUT -j OVPNINPUTRW
-A DHCPBLUEINPUT -i blue0 -j DHCPINPUT

What trigger I can use in the startup sequence to delay even more the Wireguard start so the red.up script finished the firewall part and no collisions will be made between those.

My check for ppp0 IP address (PPPD sequence finished - so red is up) in S25 script did not solved only part of the problem: dhcp, guardian, openvpn RW startup scripts no longer generate xtables.lock messages.

How a boot looks like w/o S25(wait for red to get an IP address) - this was generated from bootp, var/log/messages and dmesg -

Time (T+)	Source	Event / Action
00.00s	dmesg	Linux version 6.12.41-ipfire boot starts.
02.62s	dmesg	`red0` renamed from `eth0`.
05.47s	dmesg	`green0` ports (there are 4 green0p0-p4 ports) enter forwarding state.
06.10s	dmesg	Firewall Init #1 (S85) seen on screen
10.15s	messages	`S30dhcp` starts. Rules injected into `DHCPBLUEINPUT`.
15.22s	messages	`red0` Link is UP (1000 Mbps). Triggers `red.up`.
15.40s	dmesg	Firewall Init #2 seen on screes - [RULES WIPED] `iptables -F inside wireguard startup`
16.10s	dmesg	`S50openvpn-rw` starts. [LOCK FAILURE] `xtables.lock` busy.
16.45s	dmesg	`S50wireguard` starts. [LOCK FAILURE] `xtables.lock` busy.

After using S25 script the xtables.lock message no longer appear for dhcp, guardian and openvpn-rw.

It only appears for Wireguard

hjkl · 8 February 2026 23:38

I found a solution: the /etc/rc.d/rc3.d/S25wait-for-ppp → ../init.d/wait-for-ppp checks that ppp0 has an IP address and that /run/xtables.lock does not have a lock.

It turns out that my machine needs ~6 seconds to reload the firewall after red is up - during this time launching S50wireguard would lead to collision on /run/xtables.lock

Solution:

check_xtables_lock() {
    # 1. Open File Descriptor 9 pointing to the lock file.
    # 2. Use flock in non-blocking mode to see if the lock is held.
    # 3. Loop until lock is acquired or timeout.
    # 4. Release lock and close descriptor before exiting.

    log_event "Checking firewall lock status..."
    exec 9>"${LOCK_FILE}"

    for j in $(seq 1 ${MAX_LOCK_RETRIES}); do
        if flock -n 9; then
            log_event "Firewall lock is clear (acquired and released)."
            flock -u 9
            exec 9>&-
            return 0
        else
            log_event "Firewall process (iptables/firewallctrl) is BUSY. Waiting 2s (${j}/${MAX_LOCK_RETRIES})..."
            sleep 2
        fi
    done

    exec 9>&-
    log_event "WARNING: Proceeding without confirmed lock (Timeout)."
    return 1
}

Result: clean boot sequence:

Starting the Cyrus SASL server...
Waiting for ppp0 to appear... [ UP ]
ppp0 interface detected. Waiting 2s for hook stabilization.
Checking firewall lock status...
Firewall process (iptables/firewallctrl) is BUSY. Waiting 2s (1/10)...
Firewall process (iptables/firewallctrl) is BUSY. Waiting 2s (2/10)...
Firewall process (iptables/firewallctrl) is BUSY. Waiting 2s (3/10)...
Firewall lock is clear (acquired and released).
Setting time on boot...
Starting ntpd...

Loading Sensor Modules: coretemp
Starting Collection daemon...
Starting DHCP Server...
Starting Unbound DHCP Leases Bridge...
Starting SSH Server...
Starting Apache daemon...
Starting fcron...
Starting Guardian...
Starting OpenVPN Roadwarrior Server...
Starting OpenVPN Authenticator...
Starting WireGuard VPN...
OpenVPN N2N connection 'Black2Grey' is not enabled [ WARNING ]
Starting apcupsd daemon...

IPFire v2.29 - www.ipfire.org
==============================

All chains do have their rules now (previously those were lost)

iptables -n -L DHCPBLUEINPUT
Chain DHCPBLUEINPUT (1 references)
target     prot opt source               destination         
DHCPINPUT  all  --  0.0.0.0/0            0.0.0.0/0

bonnietwin · 9 February 2026 09:41

Can you confirm that your versions of the red, wireguard, dhcp, openvpn-n2n, openvpn-rw and tor initscripts have the changed lines with waits installed to prevent the xtables.lock message.

These were modified and released in CU199.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=3d20bc708dd24804d4da6ed311d5c04d91254a25

If you have the updated iptables commands with the wait instruction added to the six initscripts but you still then got the xtables.lock error message that would suggest that something got missed with that bug fix.

hjkl · 9 February 2026 18:39

yes, I have some of those (tor is not installed).

Squid squid does not have –wait or -w - but I am not starting squid so no impact for the moment.