ostree and fontconfig



Hi,

We've seen some interesting behaviour with fontconfig vs ostree that I
figured is worth sharing:

When new users enter graphical sessions for the first time, we've
observed a high amount of CPU time being spent inside fontconfig init,
over 30 seconds on slow systems. During this time it is generating
fontconfig caches in the user's home directory.

There are a few things at play here:

Firstly, on non-ostree systems, a system-wide fontconfig cache is
available at /var/cache/fontconfig. Ordinarily this would be used,
avoiding the need to create caches for each user. But  as ostree
starts off with a blank /var, this is not available, which is why it
proceeds to create user-level caches at runtime.

It would be possible to find a way to get /var/cache/fontconfig
populated from the initial OS build, but actually that is not optimal.
This system-wide cache is a cache of fonts shipped in the ostree
itself, which may change during updates, but /var is not included in
an ostree update. It would make more sense to have the fontconfig
cache at (say) /usr/lib/fontconfig/cache, where it will be included in
ostree updates. There is a fontconfig ./configure argument to set
this.


Secondly, even though the fontconfig cache is now shipped in the
ostree, fontconfig rejects it. The fontconfig cache files are
per-directory, and each cache file embeds the mtime of the directory
it was generated against. If the mtime embedded in the cache does not
match the directory mtime on the system, it goes ahead and regenerates
the caches in the user's home directory - no different from the
original problem.

The mtimes differ because when the font dirs and appropriate caches
are generated (on the ostree build host), they are generated with the
current time as mtime. When that is committed into an ostree, those
mtimes are not committed (probably for similar reasons that file
mtimes are also omitted). At ostree checkout time, the ostree client
creates directories with the current client time as mtime, so that is
pretty much guaranteed not to match the original mtime, meaning that
fontconfig caches will never be accepted.

One way to work around this is to force mtimes to a known constant at
both points in the process:
- When building the contents to put in the ostree, set all font dir
mtimes to 0 and then rebuild the caches with the fc-cache command. Now
the fontconfig caches embed a known mtime value (0).
- At ostree checkout/deploy time on the client, ensure that all dirs
are created with mtime 0. (There is a new commit in ostree git that
does this, matching what it was already doing for files.)

Daniel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]