[ABANDONED] tun0 interface delaying boot

[oshunluvr]

I just upgrade my Ubuntu server from 18.04 to 20.04 and this sort of forced me to watch it boot a couple times - it's headless and it only gets rebooted a couple times a month at most.

I have the VPN to not automatically start at boot because I don't normally use it. When it's needed, I launch it remotely with a script. The tun0 interface causes about 2 minutes of boot delay "waiting" for it to come on-line. I use NetworkManager because it manages the VPN interface when needed.

I wonder if anyone knows a way to tell NetworkManager to bypass or ignore the interface entirely at boot?

[GreyGeek]

Have you found the link here?
The KeyFile method or the udev rules method may work.

Or, from stackoverflow:

NetworkManager will not attempt to control a given interface if you set the interface to unmanaged using the nmcli command.

nmcli dev set wlp2s0 managed no You can verify the interface is no longer managed with the following:

nmcli dev status Output example:

DEVICE TYPE STATE CONNECTION wlp2s0 wifi unmanaged --

[claydoh]

Would disabling the systemd-networkd-wait-online service help here, or would it break something else?



EDIT:
OR modify the service:
https://manpages.ubuntu.com/manpages...service.8.html

so
sudo systemctl edit systemd-networkd-wait-online.service and add an ignore option for the interface?
I believe this creates a /something/somewhere/systemd-configurastion-thing.d/customized-setting-file

[oshunluvr]

Seems counter intuitive to mess with systemd-networkd-wait-online.service when I'm using NetworkManager so going with GG's link first:

nmcli dev status shows this:

smith@server:~$ nmcli dev status
DEVICE  TYPE      STATE        CONNECTION  
eno1    ethernet  connected    eno1        
enp2s0  ethernet  unavailable  --          
wlp3s0  wifi      unavailable  --          
lo      loopback  unmanaged    --

and this with the VPN up:

smith@server:~$ nmcli dev status
DEVICE  TYPE      STATE        CONNECTION  
eno1    ethernet  connected    eno1        
tun0    tun       connected    tun0        
enp2s0  ethernet  unavailable  --          
wlp3s0  wifi      unavailable  --          
lo      loopback  unmanaged    --

There's no MAC address for a tun device, nor is there ifcfg-* files so the next option was adding a [keyfile] entry to NetworkManager.conf with the device name. Either the 20.04 version of NM doesn't support this or it doesn't work. This did not speed up NetworkManager.wait.online.service.

I did check and the only networkd service I can locate on this system is dispatcher.

Trying the UDEV rule next...

[oshunluvr]

Well, the udev rule seemed to work, but the wait delay is the same. Oh well - I'll live with the 30secs. Thanks for the suggestions.

[claydoh]

If I am reading things correctly, yes networkmanager may be setting up and bringing up the network, but the systemd-networkd-wait-online.service still waits for a connection to be established before it allows things to move on. The default fail timeout is iirc...120 seconds

https://manpages.ubuntu.com/manpages...service.8.html

And, probably much more clearly, from from the handy dandy Arch wiki:

NetworkManager-wait-online

Enabling NetworkManager.service also enables NetworkManager-wait-online.service, which is a oneshot system service that waits for the network to be configured. The latter has WantedBy=network-online.target, so it will finish only when network-online.target itself is enabled or pulled in by some other unit. See also systemd#Running services after the network is up.

By default, NetworkManager-wait-online.service waits for NetworkManager startup to complete, rather than waiting for network connectivity specifically (see nm-online(1)). If NetworkManager-wait-online.service finishes before the network is really up, resulting in failed services on boot, extend the unit to remove the -s from the ExecStart line:

I am taking it to mean that as even if a connection is up, before NM finishes whatever it is dawdling on, the service waits for NM to report it has finished.
But I am not sure. I have always disabled the service it when it has slowed my boot/login significantly. I mean, it is what the entire internet sez to do

I didn't even think to look at the details of the actual service and options until last night.

Time to see what happens when I re-enable things on my PC.

[oshunluvr]

Not seeing what you're saying:

smith@server:~$ systemctl list-units networkd* -all
UNIT LOAD ACTIVE SUB DESCRIPTION
networkd-dispatcher.service loaded active running Dispatcher daemon for systemd-networkd

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

1 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

or maybe I just don't get it.

Since my server needs to be on the network to be, well, a server, I can live with a 30 second delay. It just seems odd that a network device that technically doesn't exist (until I launch PIA) is even found by NetworkManager. I tried everything I found to try and "fix" this but to no avail.

[Snowhog]

Look at what your systemd-networkd-wait-online.service STATE and VENDOR PRESET is showing.

systemctl list-unit-files | grep systemd-networkd-wait-online.service

[oshunluvr]

smith@server:~$ systemctl list-unit-files | grep systemd-networkd-wait-online.service
systemd-networkd-wait-online.service                                      disabled        enabled

So the "State" is disabled.