search

standardnotes / forum

Support from other community members. For 1-on-1 help, please contact help@standardnotes.com.
https://forum.standardnotes.org
196 stars 9 forks source link

[Help Wanted] Desktop Application doesn't start on Linux #2399

Closed MorgothSauron closed 1 year ago

MorgothSauron commented 1 year ago

Describe the issue The application doesn't seem to start on Linux. The AppImage has the execute flag set for my user. The main application simply don't show up.

I don't think it is related to my system because I use other AppImage that work just fine (Bitwarden, Tutanota & LBRY)

To Reproduce

  1. Verify that the AppImage has the executable flag set for the user
  2. Double-click the AppImage
  3. Wait
  4. The main application doesn't show up

Expected behavior The application windows is displayed

Screenshots N/A

Desktop (please complete the following information):

Additional context

I tried to clear the whole application config directory ($HOME/.config/Standard Notes).

I tried to start the application from the terminal and it does seem to start properly, but the main application windows is not displayed.

$ ./Applications/StandardNotes/Standard-Notes.AppImage
09:16:50.916 › Checking for update
extServer: Server started at http://127.0.0.1:45653
09:16:51.921 › PackageManager[Info]: received sync event for: Folders (1.3.8) (deleted: false), Quick Tags (1.3.2) (deleted: false), 2FA Manager (1.2.4) (deleted: false), CloudLink (1.3.1) (deleted: false), Extensions (undefined) (deleted: false)
09:16:52.187 › Update for version 3.137.1 is not available (latest version: 3.137.1, downgrade is disallowed).

The AppImage is mounted as it should:

$ mount | grep Standard
Standard-Notes.AppImage on /run/user/1000/.mount_StandaEDXUB0 type fuse.Standard-Notes.AppImage (ro,nosuid,nodev,relatime,user_id=1000,group_id=1000)
$

Content of the mounted image looks normal to me:

$ ls -al  /run/user/1000/.mount_StandaEDXUB0
total 199705
-rwxr-xr-x 1 root root      2355 Jan 11 10:38 AppRun
-rw-r--r-- 1 root root    130050 Jan 11 10:38 chrome_100_percent.pak
-rw-r--r-- 1 root root    181273 Jan 11 10:38 chrome_200_percent.pak
-rwxr-xr-x 1 root root   1160152 Jan 11 10:38 chrome_crashpad_handler
-rwxr-xr-x 1 root root     52816 Jan 11 10:38 chrome-sandbox
lrwxrwxrwx 1 root root        55 Jan 11 10:38 .DirIcon -> usr/share/icons/hicolor/512x512/apps/standard-notes.png
-rw-r--r-- 1 root root  10450240 Jan 11 10:38 icudtl.dat
-rwxr-xr-x 1 root root    250840 Jan 11 10:38 libEGL.so
-rwxr-xr-x 1 root root   2945968 Jan 11 10:38 libffmpeg.so
-rwxr-xr-x 1 root root   6460568 Jan 11 10:38 libGLESv2.so
-rwxr-xr-x 1 root root   4353928 Jan 11 10:38 libvk_swiftshader.so
-rwxr-xr-x 1 root root   6324144 Jan 11 10:38 libvulkan.so.1
-rw-r--r-- 1 root root      1096 Jan 11 10:38 LICENSE.electron.txt
-rw-r--r-- 1 root root   6648298 Jan 11 10:38 LICENSES.chromium.html
drwxr-xr-x 2 root root         0 Jan 11 10:38 locales
drwxr-xr-x 2 root root         0 Jan 11 10:38 resources
-rw-r--r-- 1 root root   5433304 Jan 11 10:38 resources.pak
-rw-r--r-- 1 root root    419816 Jan 11 10:38 snapshot_blob.bin
-rwxr-xr-x 1 root root 158959680 Jan 11 10:38 standard-notes
-rw-r--r-- 1 root root       310 Jan 11 10:38 standard-notes.desktop
lrwxrwxrwx 1 root root        55 Jan 11 10:38 standard-notes.png -> usr/share/icons/hicolor/512x512/apps/standard-notes.png
drwxr-xr-x 4 root root         0 Jan 11 10:38 usr
-rw-r--r-- 1 root root    727600 Jan 11 10:38 v8_context_snapshot.bin
-rw-r--r-- 1 root root       107 Jan 11 10:38 vk_swiftshader_icd.json
$

Running processes related to the Application

$ ps -ef|grep Standard
mcarpen+  7257     1  0 09:23 ?        00:00:01 ./Applications/StandardNotes/Standard-Notes.AppImage
mcarpen+  7314  7261  0 09:23 pts/1    00:00:00 /run/user/1000/.mount_StandaEDXUB0/standard-notes --type=gpu-process --enable-crashpad --enable-crash-reporter=4b66aa17-9426-43ec-aac5-f0f25d9d3833,no_channel --user-data-dir=/home/mcarpentier/.config/Standard Notes --gpu-preferences=WAAAAAAAAAAgAAAIAAAAAAAAAAAAAAAAAABgAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAIAAAAAAAAAABAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAA== --shared-files --field-trial-handle=0,i,10764251685216960679,16986398717344060673,131072 --disable-features=SpareRendererForSitePerProcess
mcarpen+  7335  7254  0 09:23 pts/1    00:00:00 /run/user/1000/.mount_StandaEDXUB0/standard-notes --type=utility --utility-sub-type=network.mojom.NetworkService --lang=en-US --service-sandbox-type=none --enable-experimental-web-platform-features --enable-crashpad --enable-crash-reporter=4b66aa17-9426-43ec-aac5-f0f25d9d3833,no_channel --user-data-dir=/home/mcarpentier/.config/Standard Notes --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,10764251685216960679,16986398717344060673,131072 --disable-features=SpareRendererForSitePerProcess --enable-crashpad
mcarpen+  7355  7264  0 09:23 pts/1    00:00:01 /run/user/1000/.mount_StandaEDXUB0/standard-notes --type=renderer --enable-crashpad --enable-crash-reporter=4b66aa17-9426-43ec-aac5-f0f25d9d3833,no_channel --user-data-dir=/home/mcarpentier/.config/Standard Notes --app-path=/run/user/1000/.mount_StandaEDXUB0/resources/app.asar --enable-sandbox --first-renderer-process --enable-experimental-web-platform-features --lang=en-US --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1673683572382624 --launch-time-ticks=1010367992 --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,10764251685216960679,16986398717344060673,131072 --disable-features=SpareRendererForSitePerProcess
mcarpen+  7378  7254  0 09:23 pts/1    00:00:00 /run/user/1000/.mount_StandaEDXUB0/standard-notes --type=utility --utility-sub-type=audio.mojom.AudioService --lang=en-US --service-sandbox-type=none --enable-experimental-web-platform-features --enable-crashpad --enable-crash-reporter=4b66aa17-9426-43ec-aac5-f0f25d9d3833,no_channel --user-data-dir=/home/mcarpentier/.config/Standard Notes --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,10764251685216960679,16986398717344060673,131072 --disable-features=SpareRendererForSitePerProcess --enable-crashpad
mcarpen+  7380  7264  0 09:23 pts/1    00:00:00 /run/user/1000/.mount_StandaEDXUB0/standard-notes --type=renderer --enable-crashpad --enable-crash-reporter=4b66aa17-9426-43ec-aac5-f0f25d9d3833,no_channel --user-data-dir=/home/mcarpentier/.config/Standard Notes --app-path=/run/user/1000/.mount_StandaEDXUB0/resources/app.asar --enable-sandbox --enable-experimental-web-platform-features --lang=en-US --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=7 --time-ticks-at-unix-epoch=-1673683572382624 --launch-time-ticks=1011621976 --shared-files=v8_context_snapshot_data:100 --field-trial-handle=0,i,10764251685216960679,16986398717344060673,131072 --disable-features=SpareRendererForSitePerProcess
$
zevlee commented 1 year ago

I have a somewhat similar problem. Standard Notes won't start the first time I click on it, but it will on the second click. Also, I can't seem to open the application on command line. This issue appeared in Desktop 3.137.1 for me.

MorgothSauron commented 1 year ago

Like @zevlee I noticed that starting the application a second time seems to work. It is weird because the processes for the previous start attempt are still running.

MorgothSauron commented 1 year ago

Same behavior with the latest update (3.139.0).

Clear the cache and reload doesn't help.

MorgothSauron commented 1 year ago

I noticed something really strange. The start problem seems to be related to the zoomFactor value in $HOME/.config/Standard Notes/user-preferences.json.

There is no problem to start the application when the zoomFactor is equal to 1.

However, when the zoomFactor is set to anything else (e.g. 0.9) the application window is not displayed on the first start attempt.

I was able to trigger this behavior using 3 different 'setup':

In each cases I can trigger the problem by either editing the zoomFactor directly in user-preferences.json, or by using the 'view' menu to zoom in or zoom out.

In every single test I made, the main application windows was displayed on the first try when the zoomFactor was equal to 1. It always required 2 starts when the zoomFactor had a different value.

MorgothSauron commented 1 year ago

I was able to repeat the behavior related to zoomFactor on the following distributions:

MorgothSauron commented 1 year ago

I setup few Linux virtual machines to see if there is any relation with the kernel version and/or the desktop environment.

Besides Gentoo that I customzied for my own needs, I installed the other distros using the default options. I made sure that all available updates are installed when I run the tests.

I used the AppImage available for download on the website at the time of the tests (v3.140.11).

All the tests starts with a fresh configuration, which is achieved by deleting $HOME/.config/Standard Notes. I do not sign-in with any account to rule out anything that could be related to account operations (e.g., login, synchronization)

The application is started from the command line. It is started a second time if the first attempt doesn't show the main application window.

I didn't check if there is a difference between X11 or Wayland. I simply used the default for each distribution.

If the application starts on the first try, then the test is marked as PASS. If not, the test is FAIL.

Steps:

  1. Delete configuration directory $HOME/.config/Standard Notes.
  2. Start the application (Initial Start).
  3. Close the application.
  4. Start the application, zoom out and close the application.
  5. Start the application (Start Zoom Out).
  6. Reset the zoom factor to 1 (default) using 'Actual Size'.
  7. Start the application (Start Zoom Reset).
Distribution Kernel Desktop Initial Start Start Zoom Out Start Zoom Reset
AlmaLinux 9.1 5.14.0-162 Gnome 40.4.0 PASS PASS PASS
Debian 11 5.10.0-20 Xfce 4.16 PASS FAIL PASS
Debian 11 5.10.0-21 Gnome 3.38.5 PASS PASS PASS
Fedora 37 (*) 6.1.7-200 Gnome 43.2 PASS PASS PASS
Fedora 37 6.1.7-200 KDE 5.26.5 PASS FAIL PASS
Gentoo 6.1.7 KDE 5.25.5 PASS FAIL PASS
Gentoo 5.15.89 KDE 5.25.5 PASS FAIL PASS
Manjaro 6.1.1-1 KDE 5.26.4 PASS FAIL PASS
Pop!_OS 22.04 LTS 6.0.12 Gnome 42.5 PASS PASS PASS

(*): I don't know why my previous test failed on this configuration. Maybe I wasn't 100% focused on what I was doing at that time.

Failures don't seem to be related to the kernel version. Tests failed for both 5.X and 6.X kernels.

Failures don't seem to affect Gnome. The tests failed on KDE and Xfce.

I still find it weird that the zoomFactor value could have such impact on the application startup, but it is the only value that changes between the tests.

Hope this helps.

Edit: Added Debian 11 Gnome.

MorgothSauron commented 1 year ago

Ran new tests on Manjaro (KDE + Gnome) using v3.140.13.

Distribution Kernel Desktop Initial Start Start Zoom Out Start Zoom Reset
Manjaro 6.1.7-1 KDE 5.26.5 PASS FAIL PASS
Manjaro 6.1.7-1 Gnome 43.2 PASS FAIL PASS

I didn't expect the test on Gnome to fail to be honest. I tried to start the AppImage multiples times while zoomed out (zoomFactor=0.9128....) and it never started on the first attempt. I had to start the AppImage again in a second terminal while the first one was still running to get the main window to show up.

MorgothSauron commented 1 year ago

Same problem with 3.142.1 on Gentoo with kernel 6.1.8

amanharwara commented 1 year ago

Weird that zoomFactor causes this issue. The AppImage starts fine with a different zoomFactor on my end (Manjaro KDE with 5.15 kernel).

Can you try v3.144.4? We've updated electron and some related deps, which might fix this issue...

MorgothSauron commented 1 year ago

Same behavior with v3.144.4 on Gentoo KDE with Kernel 6.1.9.

I tested with a SN configuration where I'm already logged in and with a new config. A new configuration is when I delete $HOME/.config/Standard Notes before starting the application

I also tested v3.144.4 on few other distributions:

Distribution Desktop Kernel Start Zoomed Out Start Reset Zoom
Debian 11 Xfce 5.10.0-20 FAIL PASS
Debian 11 Gnome 5.10.0-21 PASS PASS
Fedora 37 KDE 6.1.8-200 FAIL PASS
Fedora 37 Gnome 6.1.8-200 FAIL PASS
Fedora 37 Gnome 6.1.7-200 FAIL PASS

I don't understand why I have varying results on Fedora 37.

MorgothSauron commented 1 year ago

Problem still present with v3.149.5 on Gentoo (KDE) with Kernel 6.1.12

zevlee commented 1 year ago

Problem present with v3.150.0 on Fedora 37 (GNOME 43.3) with Kernel 6.1.13

MorgothSauron commented 1 year ago

Problem still present with v3.150.33 on Gentoo (KDE Plasma 5.26.5 ) with Kernel 6.2.8

MorgothSauron commented 1 year ago

Problem still present with v3.150.45 on Gentoo (KDE Plasma 5.26.5 ) with Kernel 6.2.10

MorgothSauron commented 1 year ago

I wrote down a short document where I go through the steps to setup a Manjaro Linux VM and proceed with the few tests related to the zoom level. As I expected, I was still able to reproduce the problem in this "run". sn_github2399_env_setup.pdf

edit: updated the document to redact some details.

zevlee commented 1 year ago

A quirk I recently noticed: the start up problem does not occur if the application window is maximized. If the window is anything other than maximized when it's closed, the application requires two separate clicks or terminal windows to open.

I am using Fedora Workstation 38 x86_64.

amanharwara commented 1 year ago

I think I've finally been able to replicate this issue on my end. I will look into potential fixes.

amanharwara commented 1 year ago

@MorgothSauron @zevlee Should be fixed in v3.169.6. Can you try it out and confirm?

zevlee commented 1 year ago

My testing seems to indicate that the problem was indeed fixed. I will post back here if I encounter the error again. Thank you.

MorgothSauron commented 1 year ago

I did few tests and I would say that it is indeed fixed.

I had all my previous test virtual machines (debian xfce, fedora kde and alma gnome) so I could run test there as well. All worked as expected on the different environment.

amanharwara commented 1 year ago

I did few tests and I would say that it is indeed fixed.

I had all my previous test virtual machines (debian xfce, fedora kde and alma gnome) so I could run test there as well. All worked as expected on the different environment.

Glad to hear that. Will close the issue in that case.