Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
roundoutandabout opened this issue Aug 16, 2021 · 32 comments
Open
Assignees
Labels
Desktop frontend Issues related to the desktop GUI Linux Issues related to Linux

Comments

@roundoutandabout
Copy link

roundoutandabout commented Aug 16, 2021

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"
@faern faern added Desktop frontend Issues related to the desktop GUI Linux Issues related to Linux labels Aug 17, 2021
@raksooo
Copy link
Member

raksooo commented Aug 25, 2021

@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
Copy link
Author

@raksooo yes it shows up there.

@roundoutandabout
Copy link
Author

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

@raksooo
Copy link
Member

raksooo commented Sep 1, 2021

@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
Copy link
Author

roundoutandabout commented Sep 1, 2021

@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
Copy link

@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
Copy link
Author

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

@lordcyb3r
Copy link

@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
Copy link
Member

raksooo commented Sep 6, 2021

@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
Copy link

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
Copy link
Author

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
Copy link
Author

roundoutandabout commented Sep 12, 2021

@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
Copy link
Author

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
Copy link
Member

raksooo commented Oct 13, 2021

@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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

pinkisemils commented Oct 13, 2021

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
Copy link
Member

raksooo commented Oct 14, 2021

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

@roundoutandabout
Copy link
Author

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
Copy link

Michsior14 commented Oct 20, 2021

@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
Copy link
Author

@Michsior14 yeah, that works. Thanks a lot!

@roundoutandabout roundoutandabout changed the title App window is not displayed at start-up Mullvad GUI is not launched at system start-up [workaround found] Oct 25, 2021
@Michsior14
Copy link

@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
Copy link
Member

faern commented Nov 3, 2021

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
Copy link

Michsior14 commented Nov 3, 2021

@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
Copy link
Author

@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
Copy link

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
Copy link

lotth commented Nov 20, 2022

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

lotth commented Nov 21, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Desktop frontend Issues related to the desktop GUI Linux Issues related to Linux
Projects
None yet
Development

No branches or pull requests

7 participants