VPN runs and connects successfully. But after reboot the application starts but hangs on “connecting to Mullvad system service.”
I then
sudo systemctl start mullvad-daemon.service
and it connects and runs fine.
I check in Yast under services-manager on a fresh boot and it is in fact set to start on boot but it is listed as “Inactive(Dead)” until I manually start it.
What am I doing wrong? I thought using the enable flag sets it to start on boot so that one doesn’t have to use the “start” flag every time on boot?
Who provided you with the systemd Unit file? Multivad?
My guess is that it doesn’t have a line “Requires = network.service” or something like that, so you VPN attempts to start before your regular network connection is made.
If you haven’t done this before, run the following which will read your Unit file, include any possible relevant entries in the system log and most importantly at the moment the location of the Unit file
systemctl status mullvad-daemon.service
Never edit a file directly in that location, instead copy your file to the following location with the following command, assuming that your Unit file is in the “system” and not “user” subdirectory of systemd
/etc/systemd/system/
Now, edit your copy as you see fit.
By copying the Unit file like this, your copy will take precedence over the original file, and if you ever want to return to the original (default) file, you simply delete your copy.
IMO the Unit file could be considered faulty… “Wants” might be sufficient most of the time but IMO should be “Requires” to ensure you don’t try to set up the VPN until after networking is functional.
Here is some discussion that further elaborates my point
In fact, do what I describe and replace “Wants” with “Requires” and then reboot (There is a way to invoke changes to your Unit files, but in your case you’re altering the boot flow, so why not just reboot and test right away).
That alone is not enough, you also need some service that actually waits until network is online and orders itself before network-online.target. If you are using NetworkManager, this would be NetworkManager-wait-online.service.
After=NetworkManager.service
That’s not enough either, NetworkManager startup completes as soon as daemon is started whereas it can take quite a lot of time to actually activate connection.
erlangen:~ # systemctl list-unit-files network*
UNIT FILE STATE
network.service enabled
**network-online.target static **
network-pre.target static
**network.target static **
4 unit files listed.
erlangen:~ #
erlangen:~ # journalctl -b -u systemd-networkd* -o short-monotonic
-- Logs begin at Tue 2019-09-03 21:44:16 CEST, end at Thu 2019-09-05 19:01:33 CEST. --
3.554512] erlangen systemd[1]: Starting Network Service...
4.295335] erlangen systemd-networkd[691]: Enumeration completed
** 4.295511] erlangen systemd[1]: Started Network Service.
** 4.296281] erlangen systemd[1]: Starting Wait for Network to be Configured...
8.945394] erlangen systemd-networkd[691]: eth0: Gained carrier
10.914964] erlangen systemd-networkd[691]: eth0: Gained IPv6LL
10.915733] erlangen systemd-networkd[691]: eth0: Configured
** 10.918280] erlangen systemd[1]: Started Wait for Network to be Configured.**
erlangen:~ #
On my machine fetchmail.service would start upon network.target being reached, which caused it to report some distracting errors. I told it to wait until network-online.target was reached by running ‘systemctl edit fetchmail.service’ and adding 2 lines:
I know this is an old thread, but I want to post my findings for anyone having this problem.
I have tested what tsu2 has suggested and it seems to work.
Here is what I have done.
find the location of mullvad-daemon.service
systemctl status mullvad-daemon.service
disable mullvad-daemon.service
sudo systemctl disable mullvad-daemon.service
edit mullvad-daemon.service from the location found in step 1, change ‘Wants’ to ‘Requires’
For me it works like this.
I am not sure, but I suppose this needs to be done again after every update, but I might be wrong.
I may open a ticket with Mullvad about this.
I also need to mention, that mullvad-daemon.service works without any issues in the original version (with ‘Wants’, not ‘Requires’) on Fedora, Manjaro, Arch.
So I guess there is something different on openSUSE.
Contents of /etc/systemd/system/ survive updates. Instead of using an editor and moving files users may try out “systemctl edit …”, which is more comfortable and less error prone.