shutting down whilst tunnel is active fails to set back DNS

[LaurenceJJones]

Describe the Bug

If you shutdown whilst the tunnel is active using NetworkManager (well in my case) the dns resolution on startup is set to nameserver 100.X in /etc/resolv.conf meaning you loose all DNS on startup and doing up and down does not fix this as you cannot resolve your fqdn.

Environment

N/A

To Reproduce

bring up the tunnel on the linux device, restart.

On startup cat /etc/resolv.conf is set to nameserver even though tunnel is not active.

workaround for anyone stung by this:

sudo rm /etc/NetworkManager/conf.d/olm-dns.conf

then

sudo systemctl restart NetworkManager.service

give it a couple of seconds then cat /etc/resolv.conf and it will revert back to the default nameserver for your connection.

Expected Behavior

Kinda hard since there is no daemon, but if we go daemon route then it should fallback to removing /etc/NetworkManager/conf.d/olm-dns.conf on startup if persistence is not set.

for now though we could have an cli option to cleanup and revert these files as some users may not be savvy enough to debug this on their own.

[LaurenceJJones]

Investigated this abit, so olm does in fact has a cleanup procedure but this is only called when olm.close() is called. The issue you have is obviously a race between system shutdown and when the cli (or the sub process spawned) get the pkill call.

Now we dont want the cli to have any knowledge of how to cleanup olm stale configuration, so I purpose we expose a static function on olm itself to clean this up. However, currently I believe olm itself is lacking propagation of context, so for example the up command in the cli spawns itself which should pass the ctx created from the syscall catch to olm. This means that when the call to pkill the context cancellation is propagated to olm without the explicit need to call olm.close().