search

mullvad / mullvadvpn-app

The Mullvad VPN client app for desktop and mobile
https://mullvad.net/
GNU General Public License v3.0
4.88k stars 335 forks source link

Mullvad GUI is not launched at system start-up [workaround found] #2904

Open roundoutandabout opened 3 years ago

roundoutandabout commented 3 years ago

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:

  1. In the app settings set the "Launch on start-up" option to "true"
  2. 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"
raksooo commented 3 years ago

@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
roundoutandabout commented 3 years ago

@raksooo yes it shows up there.

roundoutandabout commented 3 years ago

I tried other apps to run on startup. Firefox and LibreOffice run fine.

raksooo commented 3 years ago

@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 🙂

roundoutandabout commented 3 years ago

@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!

lordcyb3r commented 3 years ago

@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

roundoutandabout commented 3 years ago

@lordcyb3r , thanks, I'll try systemd method. Still I'm wondering why other programs start while Mullvad doesn't.

lordcyb3r commented 3 years ago

@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!

raksooo commented 3 years ago

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

lordcyb3r commented 3 years ago

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

roundoutandabout commented 3 years ago

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.

roundoutandabout commented 3 years ago

~@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

roundoutandabout commented 2 years ago

I found more recent boot log with journalctl -b:

Oct 10 01:20:39 clevo systemd[4565]: app-mullvad\x2dvpn@autostart.service: Failed to locate executable /opt/Mullvad: No such file or directory
Oct 10 01:20:39 clevo systemd[4565]: app-mullvad\x2dvpn@autostart.service: Failed at step EXEC spawning /opt/Mullvad: No such file or directory
...
Oct 10 01:20:39 clevo systemd[4249]: app-mullvad\x2dvpn@autostart.service: Main process exited, code=exited, status=203/EXEC
Oct 10 01:20:39 clevo systemd[4249]: app-mullvad\x2dvpn@autostart.service: Failed with result 'exit-code'.
Oct 10 01:20:39 clevo systemd[4249]: Failed to start Mullvad VPN.

Would this be of any help?

raksooo commented 2 years ago

@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?

roundoutandabout commented 2 years ago

@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/?

pinkisemils commented 2 years ago

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?

roundoutandabout commented 2 years ago

In the .desktop file the path is already in quotes:

Exec="/opt/Mullvad VPN/mullvad-vpn" %U

So the space should be already escaped.

pinkisemils commented 2 years ago

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.

raksooo commented 2 years ago

You could also check if the path on the bottom line in /opt/Mullvad VPN/mullvad-vpn is quoted/escaped properly.

roundoutandabout commented 2 years ago

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.

Michsior14 commented 2 years ago

@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 ;)

roundoutandabout commented 2 years ago

@Michsior14 yeah, that works. Thanks a lot!

Michsior14 commented 2 years ago

@raksooo Could mullvad produce desktop entry with Exec similar to the one I've posted above? Would be really nice to have it working ;)

faern commented 2 years ago

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.

Michsior14 commented 2 years ago

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

roundoutandabout commented 2 years ago

@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
Michsior14 commented 2 years ago

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?

lotth commented 1 year ago

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

pinkisemils commented 1 year ago

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?

Michsior14 commented 1 year ago

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.

pinkisemils commented 1 year ago

I've used standard Gnome install and then migrated to KDE.

That's exactly what I did too. I do wonder what it is we should do to reproduce the issue here.

And the main reason we wish to reproduce the it is to find what component is at fault and report a bug there - as far as we understand, as per the freedesktop specification, Exec key may have the path and arguments quoted, in which case Exec="/opt/Mullvad VPN/mullvad-vpn" %U is correct. Spawning a shell to interpret the arguments is a hack.

lotth commented 1 year ago

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.

I directly installed a Fedora KDE image, not the standard Gnome Fedora.