Snaps are still slow to launch on first time launch

Is there any progress in that area?

1 Like

Yes, we’ve determined the cause. You can follow the status at


@kenvandine - what is the plan to fix this? It seems weird that applications need to constantly update the font caches rather than just read what is there. It is unfortunate that the written caches are not snap-specific, so one snap could write caches that another snap could use (perhaps tickling bugs in fonctconfig to try to escape confinement).

That said, it seems like this could be added to desktop-legacy (because of the non-snap-specifc nature of writing to files that other snaps and session apps might use) and unity7:

owner @{HOME}/.cache/fontconfig/[0-9a-f]*.cache-[0-9] w,

@jamesh is working on figuring out why it’s attempting to open the cache rw. He didn’t like the idea of allowing write access.


So, I had been chasing a red herring for a while (looking at permission checks in the cache load/save code that could be affected by AppArmor), and missed the most obvious issue: cache versioning.

Up until Bionic, we were shipping 2.11.94, which used cache version 6. From 2.11.95 on, fontconfig has used cache version 7. If nothing outside the sandbox rebuilds version 6 caches, then there are no caches for the confined app to take advantage of, despite having read only access to the host system caches. I imagine the same will happen in reverse when we have core18 based apps running on older hosts.

As for solving the problem, I don’t think we should give write access to the fontconfig cache in the real home directory. Fontconfig memory maps the cache files with MAP_SHARED, so I’d be worried about the possibilities of a confined app causing other apps to misbehave. It is fine for a user level process to trust caches produced by root, and confined apps to trust caches produced by unconfined apps, but going in the other direction is troubling.

Arranging for cache files of a non-default version to be generated outside of confinement is probably the best option, but I’m not sure what should be responsible for handling this.


And the cache version issue doesn’t explain what’s going wrong for all of our snaps though, since anything built on top of the gnome-platform snap is using a backport of fontconfig with version 7 caches (which will have the problems outlined above when run on old Ubuntu sytems). So I need to do some more digging.


I’d really like to see the cache generation mechanism, whatever we finally achieve, to be added via a snap with a new privileged plug that only blessed snaps designed for this specific purpose are allowed to use. We could then have auto installation of these snaps triggered by installing a snap - maybe need metadata added by snapcraft based on referencing a desktop helper to indicate which version of the cache builder is needed?

I’d prefer this to be a snap with strict confinement because dogfood. That and having more magic outside in snapd for desktop scenarios requires assumptions and makes snapd bloaty mcbloater with non-portable hardcoded behaviour that we could add via snaps in a portable, easily changed, and pluggable behaviour.

The following PR should solve the font metadata rebuild issues:

The desktop-launch script generates a fonts.conf file that is intended to be included by the system ${RUNTIME}/etc/fonts/fonts.conf file to add fonts and cache locations specific to the snap. In May, a PR was merged that instead used this configuration fragment as the entire font configuration.

As well as dropping all the standard font alias logic, it also meant that /var/cache/fontconfig was no longer referenced as a cache location, so none of the global caches from the host were reused. With the May changes backed out, we should be back to the old status quo.

What I mentioned earlier is still a concern though: if we’re in a situation where the host system has version 6 caches and the snap wants version 7 caches (or vice versa), we’ll still see a rebuild on first run. But we’ve never handled that case properly, so it doesn’t represent a regression.


After installation gnome-software sends out a notification which has a button in it “launch now”.
This button does sadly not work with Snap installations.

Sounds like you need to run ubuntu-bug gnome-software to report that bug :slight_smile: