Extremely slow startup for Snaps

Hello, Every body.
Last week I have upgraded my laptop by changing the hard disk drive with a Samsung Evo SSD.
After that, i installed a fresh version of Ubuntu 20.04 on it.
There is a strange thing with Snap apps on my laptop, that caused snap Apps to take about 1-2 minutes to launch. Tested for Termius, Flameshot, Telegram snaps.

Note: It is not for first time lauch, but every time that i launch the snaps.

Snap version:
snap 2.48.2
snapd 2.48.2
series 16
ubuntu 20.04
kernel 5.8.0-41-generic

My System:
Linux ali-GE620DX 5.8.0-41-generic #46~20.04.1-Ubuntu SMP Mon Jan 18 17:52:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Thanks, Ali.

After that, I have to switch from snaps apps to traditional repository apps. Telegram and Flameshot apps now launch very fast.
But another installed snaps have very slow startup.

Any suggestion?
Let me know if more info are required.
Thanks, Ali.

You could run the snaps with the --trace-exec flag and share the output here to help us understand what’s going on, e.g.:

snap run --trace-exec telegram-desktop
1 Like

Here is the trace log for the termius snap :

ali@ali-GE620DX:~$ snap run --trace-exec termius-app
2021/02/01 23:23:16.274231 cmd_run.go:1003: WARNING: cannot start document portal: Failed to activate service ‘org.freedesktop.portal.Documents’: timed out (service_start_timeout=120000ms)
[sudo] password for ali:

(termius-app:5804): Gtk-WARNING **: 23:23:53.297: Theme parsing error: gtk.css:1566:23: ‘font-feature-settings’ is not a valid property name

(termius-app:5804): Gtk-WARNING **: 23:23:53.307: Theme parsing error: gtk.css:3616:25: ‘font-feature-settings’ is not a valid property name

(termius-app:5804): Gtk-WARNING **: 23:23:53.310: Theme parsing error: gtk.css:4078:23: ‘font-feature-settings’ is not a valid property name
(node:5804) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron. See https://github.com/electron/electron/issues/23506 for more information
(node:5804) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron. See https://github.com/electron/electron/issues/23506 for more information
(node:5933) Electron: Loading non-context-aware native module in renderer: ‘/snap/termius-app/62/resources/app.asar.unpacked/node_modules/@termius/mosh/linux-x64/moshclient.node’. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:5933) Electron: Loading non-context-aware native module in renderer: ‘/snap/termius-app/62/resources/app.asar.unpacked/node_modules/@termius/node-pty/linux-x64/pty.node’. This is deprecated, see https://github.com/electron/electron/issues/18397.
Slowest 10 exec calls during snap run:
0.248s snap-update-ns
0.558s /snap/snapd/10707/usr/lib/snapd/snap-confine
0.032s /snap/termius-app/62/desktop-init.sh
0.022s /bin/mkdir
0.317s /snap/termius-app/62/desktop-common.sh
0.019s /snap/termius-app/62/desktop-gnome-specific.sh
91.054s /snap/termius-app/62/termius-app
67.257s /proc/self/exe
67.358s /proc/self/exe
68.378s /proc/self/exe
Total time: 92.158s

Not an expert, but could you try installing xdg-desktop-portal-gtk ?

First message - 2021/02/01 23:23:16.274231 cmd_run.go:1003: WARNING: cannot start document portal: Failed to activate service ‘org.freedesktop.portal.Documents’: timed out (service_start_timeout=120000ms) - seems to indicate a two minute timeout due to communication (lack of) with XDG Portals, which is consistent with your symptoms.

I have already installed the “xdg-desktop-portal-gtk” package.

Reading package lists… Done
Building dependency tree
Reading state information… Done
xdg-desktop-portal-gtk is already the newest version (1.6.0-1build1).
0 upgraded, 0 newly installed, 0 to remove and 53 not upgraded.

Also, found another related post here. In that case, the issue was with the flatpak and .local/shared folder permission.

I do not have flatpak installed in my system.
and change the owner of folder to current user by:

sudo chown -R $ali:$ali ~/.local/share/

The issue is still there.

You shouldn’t have replaced USER with your username, $USER is an environment variable that resolves to “ali” in your case. The correct command is:

sudo chown -R $USER:$USER ~/.local/share/

You are right. It’s a typo.
After running the
sudo chown -R $USER:$USER ~/.local/share/
or
sudo chown -R ali:ali ~/.local/share/

The issue is exists.

Do you mean the problem is fixed, or still exists?

The issue is still exists.

Do you run any exotic desktop setup or is this just a stock ubuntu ? (since nobody else seems to have such issues it must be something with your local environment after all)…

After having applied all the suggestions, can you run snap run --trace-exec termius-app again and post the results you’re getting now?

It’s a fresh installation of Ubuntu 20.04 LTS.
I just install some apps and extensions. One of them was material-shell. I had a try and then uninstall it.

I don’t know if it could be a problem.

After applying some changes, here is the trace log:
ali@ali-GE620DX:~$ snap run --trace-exec termius-app
2021/02/02 16:02:41.578088 cmd_run.go:1003: WARNING: cannot start document portal: Failed to activate service ‘org.freedesktop.portal.Documents’: timed out (service_start_timeout=120000ms)
[sudo] password for ali:

(termius-app:49892): Gtk-WARNING **: 16:03:17.612: Theme parsing error: gtk.css:1566:23: ‘font-feature-settings’ is not a valid property name

(termius-app:49892): Gtk-WARNING **: 16:03:17.619: Theme parsing error: gtk.css:3616:25: ‘font-feature-settings’ is not a valid property name

(termius-app:49892): Gtk-WARNING **: 16:03:17.620: Theme parsing error: gtk.css:4078:23: ‘font-feature-settings’ is not a valid property name
(node:49892) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron. See https://github.com/electron/electron/issues/23506 for more information
(node:49892) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron. See https://github.com/electron/electron/issues/23506 for more information
(node:50000) Electron: Loading non-context-aware native module in renderer: ‘/snap/termius-app/62/resources/app.asar.unpacked/node_modules/@termius/mosh/linux-x64/moshclient.node’. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:50000) Electron: Loading non-context-aware native module in renderer: ‘/snap/termius-app/62/resources/app.asar.unpacked/node_modules/@termius/node-pty/linux-x64/pty.node’. This is deprecated, see https://github.com/electron/electron/issues/18397.

when you removed it, did you exactly follow the “Uninstallation” process described, so you dont have any leftovers around that could break your desktop ?

Sure, I did these two steps :

  1. Open gnome-tweaks and disable the Material Shell extension OR disable it using
    gnome-extensions disable material-shell@papyelgringo

  2. Delete the extension directory.
    rm -rf ~/.local/share/gnome-shell/extensions/material-shell@papyelgringo

I am receiving somewhat similar error messages as of this morning on a previously working system.

I have a stock (recently-installed) ubuntu 20.04.
As mentioned Chromium was previously working on this install.
This morning it will start but cannot connect to the internet
Error messages
Gtk-WARNING **: 10:55:29.456: Theme parsing error: gtk.css:1566:23: ‘font-feature-settings’ is not a valid property name

Gtk-WARNING **: 10:55:29.460: Theme parsing error: gtk.css:3616:25: ‘font-feature-settings’ is not a valid property name

Gtk-WARNING **: 10:55:29.461: Theme parsing error: gtk.css:4078:23: ‘font-feature-settings’ is not a valid property name

I don’t know if it is related to the issue.
Is it a snap version of chromium?
In my case, the cause of latency is due to timeout as specified:
2021/02/02 16:02:41.578088 cmd_run.go:1003: WARNING: cannot start document portal: Failed to activate service ‘org.freedesktop.portal.Documents’: timed out (service_start_timeout=120000ms)

@ogra What do you think?

yes, this is definitely related to the portal not starting and the process waiting for the timeout first …