mullvadvpn-app
mullvadvpn-app copied to clipboard
Mullvad GUI is not launched at system start-up [workaround found]
Issue report
Operating system: Fedora 34 KDE
App version: 2021.3
Issue description
I have a Mullvad desktop app set to launch on start-up. Also "Start minimized" is set to false. At the system start-up I get connected to the VPN, so the Mullvad daemon apparently starts, but no application window launches. I have to launch it manually.
How reproducible:
Always
Steps to reproduce:
- In the app settings set the "Launch on start-up" option to "true"
- Restart the system
Expected result:
Main app window launches at system start-up
Observed result:
Main app window doesn't launch at system start-up neither maximized nor in the tray.
UPDATE:
Seems like the space in the path to the mullvad-vpn
script is not escaped properly.
Workaround is to edit the /usr/share/applications/mullvad-vpn.desktop
:
Exec=sh -c "'/opt/Mullvad VPN/mullvad-vpn' %U"
@roundoutandabout Does the mullvad-vpn.desktop
file show up in the autostart directory? You can check by running this in a terminal
ls ${XDG_CONFIG_HOME:-"$HOME/.config"}/autostart | grep mullvad
@raksooo yes it shows up there.
I tried other apps to run on startup. Firefox and LibreOffice run fine.
@roundoutandabout Hmm okay, I haven't been able to reproduce this unfortunately. Can you check if the app is running (it could be that it just isn't visible).
ps aux | grep mullvad-gui
It would also be helpful if you sent a problem report from within the app. I would then be able to read the app logs. Please write in the problem report description that you've talked to med here 🙂
@raksooo , the app is not running, I get only this in the output:
user 5658 0.0 0.0 221396 788 pts/1 S+ 22:45 0:00 grep --color=auto mullvad-gui
I've sent the problem report!
@raksooo , the app is not running, I get only this in the output:
user 5658 0.0 0.0 221396 788 pts/1 S+ 22:45 0:00 grep --color=auto mullvad-gui
I've sent the problem report!
here is a workaround you could try for now, I did something similar in ubuntu when my audio service wouldnt start at login. Its a bit hacky but I think it will work here. https://forum.level1techs.com/t/run-command-at-startup-fedora-25/116989
@lordcyb3r , thanks, I'll try systemd method. Still I'm wondering why other programs start while Mullvad doesn't.
@lordcyb3r , thanks, I'll try systemd method. Still I'm wondering why other programs start while Mullvad doesn't.
yeah, no clue. Doesnt seem to be an issue for me with popos on my laptop (ubuntu based). Post an update if the workaround works please!
@roundoutandabout I've had a look at the logs and didn't find anything interesting unfortunately. I've also tried to reproduce this but without success. We won't look further into this now unless it's a more common issue than we think.
The app isn't supposed to run as root so make sure to run it as your user if you launch it with systemd.
Does fedora support startup commands like those in ubuntu? if so you can just set a command to start mullvad gui when your user signs in. That way it does not run as root
Does fedora support startup commands like those in ubuntu? if so you can just set a command to start mullvad gui when your user signs in. That way it does not run as root
Yes, all .desktop
files in ~/.config/autostart
are supposed to run during startup.
~@raksooo , I found in journalctl
this line, which might be useful:~
Jun 12 17:11:01 fedora systemd-xdg-autostart-generator[3264]: stat() failed on /home/user/.config/autostart/mullvad-vpn.desktop, ignoring: No such file or directory
Sorry, this is some old log
I found more recent boot log with journalctl -b
:
Oct 10 01:20:39 clevo systemd[4565]: app-mullvad\[email protected]: Failed to locate executable /opt/Mullvad: No such file or directory
Oct 10 01:20:39 clevo systemd[4565]: app-mullvad\[email protected]: Failed at step EXEC spawning /opt/Mullvad: No such file or directory
...
Oct 10 01:20:39 clevo systemd[4249]: app-mullvad\[email protected]: Main process exited, code=exited, status=203/EXEC
Oct 10 01:20:39 clevo systemd[4249]: app-mullvad\[email protected]: Failed with result 'exit-code'.
Oct 10 01:20:39 clevo systemd[4249]: Failed to start Mullvad VPN.
Would this be of any help?
@roundoutandabout Looks like it's from a systemd-service. As far as I'm aware there's no service with that name in our app. Did you create this one yourself?
@raksooo no I didn't create a service. In /etc/systemd/system/
there is only mullvad-daemon.service
.
Isn't systemd starting apps from ~/.config/autostart/
?
Going by the logs, it seems like the path to our app isn't escaped properly. If you were to change the autostart file for our app to either quote the spaces in the path or just put the whole path in quotes, would that help?
In the .desktop
file the path is already in quotes:
Exec="/opt/Mullvad VPN/mullvad-vpn" %U
So the space should be already escaped.
Failed at step EXEC spawning /opt/Mullvad: No such file or directory
This line implies that the space might need to be escaped even if the string is quoted.
You could also check if the path on the bottom line in /opt/Mullvad VPN/mullvad-vpn
is quoted/escaped properly.
I tried escaping the space in .desktop
file as Exec="/opt/Mullvad\ VPN/mullvad-vpn" %U
, but this doesn't work.
In /opt/Mullvad VPN/mullvad-vpn
I tried explicitly defining the exec path as "/opt/Mullvad VPN//mullvad-gui", also no luck.
I'm definitely missing something, because I can without problems launch .desktop
file and mullvad-vpn
script manually after system startup.
@roundoutandabout I had the same issue and resolved it by modifying the .desktop
file to:
[Desktop Entry]
Name=Mullvad VPN
Exec=sh -c "'/opt/Mullvad VPN/mullvad-vpn' %U"
Terminal=false
Type=Application
Icon=mullvad-vpn
StartupWMClass=Mullvad VPN
Comment=Mullvad VPN client
Categories=Network;
As far as I know there is different command parsing for Exec
than it's normally done in shell and for some systems it doesn't like spaces, even when escaped with \
or "
. That's why sh
should be more reliable with spaces ;)
@Michsior14 yeah, that works. Thanks a lot!
@raksooo Could mullvad produce desktop entry with Exec
similar to the one I've posted above? Would be really nice to have it working ;)
What version of systemd are you running? Question directed to everyone who has this issue :) Since it works for the vast majority of Linux users (including Fedora 34 KDE) there must be something that is different on your systems.
@faern The version I have on Fedora 35 KDE is:
systemd 249 (v249.4-2.fc35)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
Although I had the same issue on Fedora 34 KDE in past, but never had look on it.
@faern for me on Fedora 34 KDE:
systemd 248 (v248.9-1.fc34)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
Fedora 36 KDE (still beta) is also affected:
systemd 250 (v250.3-8.fc36)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
Might it be that zsh shell is causing this issue?
Fedora 37 KDE (updated from Fedora 36) is also affected.
systemd 251 (251.8-586.fc37) +PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
I wonder if it's a locale problem, since I can not reproduce this in a fresh VM on Fedora 37 with both Gnome and KDE with the British and Ukranian locale, and it just works. And the version of systemd
here is the same yours @lotth .
I used the workstation ISO to setup my VM, did any of you perhaps install the server version and then install the desktop packages yourselves?
I wonder if it's a locale problem, since I can not reproduce this in a fresh VM on Fedora 37 with both Gnome and KDE with the British and Ukranian locale, and it just works. And the version of
systemd
here is the same yours @lotth .I used the workstation ISO to setup my VM, did any of you perhaps install the server version and then install the desktop packages yourselves?
I am using en-US
and still experiencing this issue (Fedora 34-37 KDE). I've used standard Gnome install and then migrated to KDE.