Bug 103652

Hmm, what does "not seem to support" really mean here? are you generating a cache on non-squashfs and using it on squashfs then?

I believe that what bug reporter means is that the cache is added to the squashfs during the build of the livecd and at boot when FC tries to check the freshness of the cache it decides that it needs to be updated and then write a fresh one to the unionfs (I suppose)

Can you give me a log of FC_DEBUG=16 fc-cache prior to boot the desktop?

Created attachment 138574 [details]
output of FC_DEBUG=16 fc-cache

I attached the output of FC_DEBUG=16 fc-cache before booting to an Ubuntu Desktop Live Session. This is a follow-up of the issue reported in LP (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1754836) where, according to latest comments), the font cache is regenerated when the user session starts. 
Let me know if you need more information.

Created attachment 138578 [details] [review]
cache: If nsec is zero, don't use it for comparisons

I made a (stupid?) patch. Is this a reliable way to go about falling back from nsec to non-nsec? I couldn't find a way to actually ask the question of the system directly.

We're particularly interested because this is a big cause of live image boot slowness on Ubuntu. This patch works as intended; the cache isn't regenerated on live system boot any more.

The problem as I understand it:

1. You have /usr/share/fonts/* on ext4 or similar FS with nanos.
2. /usr/share/fonts has a timestamp like 1522818676.601423551.
3. You run fontconfig and it stores the timestamp in the cache file.
4. You build a squashfs from the FS. Squashfs does not support nanos.
5. The timestamp of /usr/share/fonts inside the squashfs becomes 1522818676.0.
6. Installer boots and fontconfig sees the mismatched time stamps so rebuilds the cache in the live user's home directory - which is wiped at reboot.
7. During install the squashfs is copied back to an ext4 FS.
8. User reboots and logs in.
9. /usr/share/fonts is now on a filesystem which supports nanos, but the original time stamp nanos has been lost.
10. Fontconfig decides the cache is out of date and rebuilds it again, in the new user's home directory. This happens each time a newly created user logs in, until such time as a postinst script rebuilds the system font cache.

Note steps 9 and 10 only happen on Xubuntu and maybe some other flavours, but not Ubuntu.

This means that even if you could ask the system whether the filesystem supports nanos, that wouldn't be enough. It is possible for the timestamp information to be lost/mutated through squashfs, and then copied back to a filesystem with nanos, and then there is no way to determine whether that has happened or not.

Your analysis is correct. 

point 9 doesn't happen on Ubuntu (and maybe other flavours) because at the end of te installation process, some packages are removed from the target filesystem that triggers the fontconfig trigger (which runs the postinst script that regenerate the cache) So on next boot the timestamps won't have nanoseconfs but will match.

Aren't this:

(In reply to Alistair Buxton from comment #6)
> 5. The timestamp of /usr/share/fonts inside the squashfs becomes
> 1522818676.0.
> 6. Installer boots and fontconfig sees the mismatched time stamps so
> rebuilds the cache in the live user's home directory - which is wiped at
> reboot.
> 7. During install the squashfs is copied back to an ext4 FS.

and this:

> 8. User reboots and logs in.
> 9. /usr/share/fonts is now on a filesystem which supports nanos, but the
> original time stamp nanos has been lost.
> 10. Fontconfig decides the cache is out of date and rebuilds it again, in
> the new user's home directory. This happens each time a newly created user
> logs in, until such time as a postinst script rebuilds the system font cache.

actually the same thing happening twice? The nanosecond portion of the timestamp is lost when the squashfs is built, and it's still not there when it's copied to the target system, but the fontconfig cache has nanos in it.

In that case, my proposed fix fixes this. I tried with a modified Xubuntu ISO, and after installation:

laney@bionic:~$ ls -l .cache
total 24
-rw-rw-r-- 1 laney laney    5 Apr  5 12:52 blueman-applet-1000
drwxr-xr-x 2 laney laney 4096 Apr  5 12:52 gstreamer-1.0
-rw-r--r-- 1 laney laney    0 Apr  5 13:05 motd.legal-displayed
drwx------ 2 laney laney 4096 Apr  5 12:53 obexd
drwx------ 2 laney laney 4096 Apr  5 12:52 sessions
drwxrwxr-x 2 laney laney 4096 Apr  5 13:01 update-manager-core
-rw-rw-r-- 1 laney laney  381 Apr  5 12:52 xfce4-indicator-plugin.log

(laney@bionic:~$ stat /usr/share/fonts
...
Modify: 2018-04-04 06:44:44.000000000 +0100
laney@bionic:~$ FC_DEBUG=16 fc-cache
FC_DEBUG=16
FcCacheTimeValid dir "/usr/share/fonts" cache checksum 1522820684.549609025 dir checksum 1522820684.0
tv_nsec == 0, ignoring nanoseconds)

Yes, your current patch handles both cases.

My point was that if you "improve" the patch to check whether the filesystem supports nanos it would no longer handle the second case.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/44.