Can't get service to start on boot

Mullvad VPN won’t enable on boot.

sudo systemctl enable mullvad-daemon.service
sudo systemctl start mullvad-daemon.service

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?

Thanks

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.

TSU

This is starting to make more sense to me after reading your generous response.

systemctl status mullvad-daemon.service

● mullvad-daemon.service - Mullvad VPN daemon
Loaded: loaded (/opt/Mullvad VPN/resources/mullvad-daemon.service; enabled; vendor preset: disabled)
Active: inactive (dead)

Here is the file output in /opt:

# Systemd service unit file for the Mullvad VPN daemon

[Unit]
Description=Mullvad VPN daemon
Wants=network.target
After=network-online.target
After=NetworkManager.service
After=systemd-resolved.service
StartLimitBurst=5
StartLimitIntervalSec=20

[Service]
Restart=always
RestartSec=1
ExecStart=/opt/Mullvad\x20VPN/resources/mullvad-daemon -v --disable-stdout-timestamps

[Install]
WantedBy=multi-user.target

I was able to find the exact same file in /etc/systemd/service

So does this mean I need to edit the file in /opt and copy it to the /etc directory? If so, is there a line I should add and in what part of the file?

Thanks for your help with this. I’m getting closer to understanding.

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).

TSU

It sounds like it starts before network is up.

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.

Thanks for the resources. This has become to complicated for me so I need to move on.

Thanks for the information. This is all above my head so I need to move on.

There are two targets related to networking:

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:

erlangen:~ # systemctl cat fetchmail.service 
# /usr/lib/systemd/system/fetchmail.service
[Unit]
Description=A remote-mail retrieval utility
After=network.target

[Service]
EnvironmentFile=-/etc/sysconfig/fetchmail
User=fetchmail
ExecStart=/usr/lib/fetchmail-systemd-exec
RestartSec=1

[Install]
WantedBy=multi-user.target

# **/etc/systemd/system/fetchmail.service.d/override.conf**
**[Unit]
After=network-online.target
**erlangen:~ # 

Now fetchmail.service waits until network-online.target is reached (links are configured)

erlangen:~ # journalctl -b -u fetchmail.service -o short-monotonic 
-- Logs begin at Tue 2019-09-03 21:44:16 CEST, end at Thu 2019-09-05 19:12:09 CEST. --
**   10.923745] erlangen systemd[1]: Started A remote-mail retrieval utility.**
   10.938396] erlangen fetchmail[1141]: starting fetchmail 6.3.26 daemon
erlangen:~ # 

Hello!

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.

  1. find the location of mullvad-daemon.service
systemctl status mullvad-daemon.service
  1. disable mullvad-daemon.service
sudo systemctl disable mullvad-daemon.service
  1. edit mullvad-daemon.service from the location found in step 1, change ‘Wants’ to ‘Requires’
sudo nano /opt/Mullvad\ VPN/resources/mullvad-daemon.service
# Systemd service unit file for the Mullvad VPN daemon

[Unit]
Description=Mullvad VPN daemon
**#Wants=network.target
Requires=network.target**
After=network-online.target
After=NetworkManager.service
After=systemd-resolved.service
StartLimitBurst=5
StartLimitIntervalSec=20

[Service]
Restart=always
RestartSec=1
ExecStart=/opt/Mullvad\x20VPN/resources/mullvad-daemon -v --disable-stdout-timestamps

[Install]
WantedBy=multi-user.target
  1. copy service file to systemd/system folder:
sudo cp -i /opt/Mullvad\ VPN/resources/mullvad-daemon.service /etc/systemd/system/
  1. enable service
sudo systemctl enable mullvad-daemon.service
  1. reboot system to test it

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.

Cheers!

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.

Thanks @karlmistelberger for the tip!

I have read about “systemctl edit” a bit more and tried it out. It is the proper way to edit service files.

So instead of editing and copying files, I would suggest:


sudo systemctl edit --full mullvad-daemon.service

A new discovery is that it is enough to change Wants to:

Wants=network-online.target

and the service will start properly.

Cheers!

Can you guys clarify–are you using the Fedora RPM from the Mullvad download site?

I believe that is the only way without using wireguard or openvpn, but I just wanted to be sure.

I am experiencing the same issue, but considering I can even get my VPN to work using the Fedora RPM, I’m extremely happy.

I wanted to thank you. This works for me. Cheers.