Service shutdown leaves bypass route residue in the bypass table #78

New issue

Closed

opened 2026-08-19 23:17:47 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-19 23:17:47 -04:00

Owner

Observed live 2026-08-19 while verifying the #66 fix: after systemctl restart aqomui with a main + bypass connection up, table 11 still held the pre-launch host-route pin to the bypass server:

$ ip route show table 11
89.222.100.66 via 192.168.0.1 dev enp5s0

The pin is added before the bypass tunnel launches and removed in the disconnect teardown (#75) — but a service stop goes through SIGTERM, which kills the OpenVPN processes without running the Python-side route cleanup, so anything the teardown owns (the table-11/main-table pins, a table-11 default) can survive the restart.

Mostly harmless: the pin only affects marked traffic to that one server IP and would be re-added on the next connect to the same server. But it's the same failure shape that produced #66 — state parked in table 11 outliving the process that put it there. Shutdown should sweep it: either run the route teardown from a SIGTERM handler before exit, or flush the service-owned entries from table 11 in startup's clean-slate block (which already does killall openvpn).

Related symptom from the same restart, relevant to #24/#73: with the GUI running across the restart, it still showed the main connection as connected while the bypass connection was gone — neither tunnel had actually survived (openvpn: no process found in the start log). That's stale GUI state with no reconciliation, i.e. #24's problem statement observed live.

Observed live 2026-08-19 while verifying the #66 fix: after `systemctl restart aqomui` with a main + bypass connection up, table 11 still held the pre-launch host-route pin to the bypass server: ``` $ ip route show table 11 89.222.100.66 via 192.168.0.1 dev enp5s0 ``` The pin is added before the bypass tunnel launches and removed in the disconnect teardown (#75) — but a service stop goes through SIGTERM, which kills the OpenVPN processes without running the Python-side route cleanup, so anything the teardown owns (the table-11/main-table pins, a table-11 default) can survive the restart. Mostly harmless: the pin only affects marked traffic to that one server IP and would be re-added on the next connect to the same server. But it's the same failure shape that produced #66 — state parked in table 11 outliving the process that put it there. Shutdown should sweep it: either run the route teardown from a SIGTERM handler before exit, or flush the service-owned entries from table 11 in startup's clean-slate block (which already does `killall openvpn`). Related symptom from the same restart, relevant to #24/#73: with the GUI running across the restart, it still showed the main connection as connected while the bypass connection was gone — neither tunnel had actually survived (`openvpn: no process found` in the start log). That's stale GUI state with no reconciliation, i.e. #24's problem statement observed live.

mysticalsoap added the

bug

label

2026-08-19 23:17:47 -04:00

mysticalsoap referenced this issue from a pull request that will close it,

2026-08-20 20:56:12 -04:00

fix: sweep stale bypass routes at service startup #108

mysticalsoap referenced this issue from a commit

2026-08-20 20:56:12 -04:00

fix: sweep stale bypass routes at service startup

mysticalsoap closed this issue

2026-08-20 21:16:03 -04:00