Linux App not Launching / .lock file

alexknop commented 1 year ago

Proton Mail Bridge App is not launching due to an error with a .lock file.

Expected Behavior

App should start when commanded.

Current Behavior

Clicking on the App Icon isn't showing any behavior, launching from CLI is showing an error.

Possible Solution

Better handling of .lock files

Steps to Reproduce

Launch protonmail-bridge on Debian 12 after it has already been installed and system has been rebooted:

alex@debian:~$ protonmail-bridge INFO[Jun 15 16:42:20.585] bridge-gui starting INFO[Jun 15 16:42:20.585] Using Qt 6.3.2 ERRO[Jun 15 16:42:20.585] Instance already exists /home/alex/.cache/protonmail/bridge-v3/bridge-v3-gui.lock (PID : 3212 - Host : alex-Blade-15-2022-RZ09-0421 - App : bridge-gui)

.lock file can be removed and then proton bridge launches:

alex@debian:~$ rm .cache/protonmail/bridge-v3/bridge-v3-gui.lock alex@debian:~$ protonmail-bridge INFO[Jun 15 12:46:33.699] bridge-gui starting INFO[Jun 15 12:46:33.699] Using Qt 6.3.2 INFO[Jun 15 12:46:33.715] lock file created /home/alex/.cache/protonmail/bridge-v3/bridge-v3-gui.lock INFO[Jun 15 12:46:33.721] Launching bridge process with command "/usr/lib/protonmail/bridge/bridge" --grpc --parent-pid 5111 --launcher /usr/lib/protonmail/bridge/proton-bridge INFO[Jun 15 12:46:33.722] Retrieving gRPC service configuration from '/home/alex/.config/protonmail/bridge-v3/grpcServerConfig.json' time="2023-06-15T12:46:33-04:00" level=info msg="Migrating keychain helper" WARN[Jun 15 12:46:34.037] QSystemTrayIcon::setVisible: No Icon set WARN[Jun 15 12:46:34.037] QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*) WARN[Jun 15 12:46:34.047] QPainter::begin: Paint device returned engine == 0, type: 2 WARN[Jun 15 12:46:34.048] QPainter::setCompositionMode: Painter not active WARN[Jun 15 12:46:34.048] QPainter::end: Painter not active, aborted INFO[Jun 15 12:46:34.048] Connecting to gRPC service INFO[Jun 15 12:46:34.048] Connection to gRPC server at unix:///tmp/bridge4842. attempt #1 INFO[Jun 15 12:46:34.052] Successfully connected to gRPC server. INFO[Jun 15 12:46:34.052] Client config file was saved to '/home/alex/.config/protonmail/bridge-v3/grpcClientConfig_0.json' INFO[Jun 15 12:46:34.052] gRPC token was validated INFO[Jun 15 12:46:34.052] Connected to backend via gRPC service.

The application can be closed/opened as needed from here on, but the problem resurfaces after a reboot.

Version Information

3.2

Context (Environment)

Debian 12 GNOME 43.4 Kernel 6.1.0

Detailed Description

I do have the setting on to have Proton Mail Bridge automatically start.

Possible Implementation

Not sure what .lock files use is, but can it be removed as part of shutting down the service?

LBeernaertProton commented 1 year ago

Hey @alexknop we are currently using QLockFile to handle this and this should delete the lock file automatically when the application shuts downs. It should also handle stale lock files due to crashes, among other cases.

Is this always reproducible for you?

alexknop commented 1 year ago

Yes it is. How can I get some logs to verify what QLockFile is doing?

alexknop commented 1 year ago

Hey @alexknop we are currently using QLockFile to handle this and this should delete the lock file automatically when the application shuts downs. It should also handle stale lock files due to crashes, among other cases.

Also, I have noticed that the gui.lock file is deleted when I open bridge and click on the Menu>Quit bridge. However, the timestamps of my .lock files did not change when I rebooted my system. It's possible when the application shuts down due to reboot, etc, and not by manual Quitting that the .lock file(s) is not actually being removed. Perhaps ensuring this will fix my issue.

LBeernaertProton commented 1 year ago

According to QLockFile's Documentation this should be the case.

Is it possible there may be perhaps two auto-start configurations that are interfering with one-another?

alexknop commented 1 year ago

Well it is not removing the .lock file when restarting. So maybe that is what is wrong here.

And also yes it is possible there are conflicting auto-start configs, but how would I check?

LBeernaertProton commented 1 year ago

The autostart file should be in one of the following locations:

$HOME/.config/autostart/Proton\ Mail\ Bridge.desktop
$XDG_CONFIG_HOME/autostart/Proton\ Mail\ Bridge.desktop

alexknop commented 1 year ago

Unfortunately, that is not the case.

alex@debian:~$ ls -l .config/autostart/Proton\ Mail\ Bridge.desktop -rw-rw-r-- 1 alex alex 150 Jun 15 12:38 '.config/autostart/Proton Mail Bridge.desktop'

I do not have anything assigned to that XDG variable:

alex@debian:~$ env | grep XDG XDG_MENU_PREFIX=gnome- XDG_SESSION_DESKTOP=gnome XDG_SESSION_TYPE=x11 XDG_CURRENT_DESKTOP=GNOME XDG_SESSION_CLASS=user XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

So I think the problem is the lock file is not being removed when restarting my computer.

rlejeune74 commented 1 year ago

HI @alexknop, good to know that the autostart files are not messed up.

The fact that the lock file stays is not an issue per se, the expected behavior of a QFileLock is that when you try to acquire the lock:

if the lock file doesn't exist => create the lock file and continue
if the lock file exists and match a running process => fails to acquire the lock and fail
if the lock file exists and does not match a running process => replace the lock file information by this running process information (acquire the lock) and continue

Based on what you described, you should be ending in the third option.

Would you be willing to give us more details to sort this out ?

Do you observe the same behavior when disabling the autostart option ? (to definitely exclude the autostart issue)
When you reproduce the issue, does the leftover lock file information matches an existing process ? (first line of ~/.cache/protonmail/bridge-v3/bridge-v3-gui.lock is the PID)

alexknop commented 1 year ago

The lock file is not matching an existing process. So it seems the third bullet point is not working:

if the lock file exists and does not match a running process => replace the lock file information by this running process information (acquire the lock) and continue

rlejeune74 commented 1 year ago

I'm opening an internal ticket (GODT-2781). We will investigate those 2 described cases :

@alexknop I will let you know as soon as we have a test build for this.

Izbhle commented 1 year ago

Hi, i am facing the same issue, and can add some observations (Fedora 38 with KDE Plasma) Using Poton-Bridge (3.3.2) Flatpak The following steps always produce the same behavior:

Have the bridge running
Exit the user session with a logout
Create another user Session for the same User

From that point on the error occurs when the bridge is started, until either the lock file is manually deleted, or the system is restarted. Auto start does not seem to affect this behavior.

alfredonodo commented 11 months ago

Hi, I have the same problem with ubuntu LTS 22.04 and latest protonmailBridge.

alexknop commented 10 months ago

@rlejeune74 it appears this is fixed in version 3.5.3

alfredonodo commented 10 months ago

@rlejeune74 it appears this is fixed in version 3.5.3

I can confirm.

LBeernaertProton commented 10 months ago

Closing ticket based on feedback from @alexknop and @alfredonodo

adingbatponder commented 10 months ago

This issue arises in nixos when using their repo https://search.nixos.org/packages?channel=23.05&show=protonmail-bridge&from=0&size=50&sort=relevance&type=packages&query=protonmail

. Perhaps they do no have fixed version ? [--@thinky1:~]$ protonmail-bridge --cli INFO[0000] Migrating keychain helper
WARN[Oct 29 09:56:38.305] Failed to create lock file; another instance is running

rlejeune74 commented 10 months ago

. Perhaps they do no have fixed version ?

indeed @adingbatponder, from the link you shared: Name: protonmail-bridgeVersion: 3.1.2

ProtonMail / proton-bridge