Arch Linux

Just see that there is also a thread about the issue:
https://bbs.archlinux.org/viewtopic.php?id=240026

quickly skimming over the affected directories, it looks like this is caused by directories with 0 fonts in them. Maybe the behavior in this case has changed recently.

Reported upstream at https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/107

I would like to point out that it happens also with directories containing files in them (but indeed no fonts). In my case:

(1/6) upgrading fontconfig [#############################################################################] 100%
Rebuilding fontconfig cache.../usr/share/fonts/encodings/large: failed to write cache
done.

ls -l /usr/share/fonts/encodings/large
total 624
-rw-r--r-- 1 root root 64280 May 31 05:03 big5.eten-0.enc.gz
-rw-r--r-- 1 root root 85154 May 31 05:03 big5hkscs-0.enc.gz
-rw-r--r-- 1 root root 29723 May 31 05:03 cns11643-1.enc.gz
-rw-r--r-- 1 root root 36755 May 31 05:03 cns11643-2.enc.gz
-rw-r--r-- 1 root root 26144 May 31 05:03 cns11643-3.enc.gz
-rw-r--r-- 1 root root 925 May 31 05:03 encodings.dir
-rw-r--r-- 1 root root 140 May 31 05:03 gb18030-0.enc.gz
-rw-r--r-- 1 root root 65442 May 31 05:03 gb18030.2000-0.enc.gz
-rw-r--r-- 1 root root 1664 May 31 05:03 gb18030.2000-1.enc.gz
-rw-r--r-- 1 root root 70451 May 31 05:03 gb2312.1980-0.enc.gz
-rw-r--r-- 1 root root 59047 May 31 05:03 gbk-0.enc.gz
-rw-r--r-- 1 root root 441 May 31 05:03 jisx0201.1976-0.enc.gz
-rw-r--r-- 1 root root 72667 May 31 05:03 jisx0208.1990-0.enc.gz
-rw-r--r-- 1 root root 23831 May 31 05:03 jisx0212.1990-0.enc.gz
-rw-r--r-- 1 root root 34655 May 31 05:03 ksc5601.1987-0.enc.gz
-rw-r--r-- 1 root root 32398 May 31 05:03 ksc5601.1992-3.enc.gz
-rw-r--r-- 1 root root 855 May 31 05:03 sun.unicode.india-0.enc.gz

Strace log:
unlink("/usr/share/fonts/util/.uuid") = 0
stat("/usr/share/fonts/util", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/share/fonts/util", O_RDONLY|O_CLOEXEC) = 3
fstatfs(3, {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=10264464, f_bfree=3852494, f_bavail=3325326, f_files=2616320, f_ffree=2245781, f_fsid={val=[1232134085, 1097470473]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
close(3) = 0
openat(AT_FDCWD, "/var/cache/fontconfig/dc9fcae7-af10-4879-81bc-6576285b39e6-le64.cache-7", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=104, ...}) = 0
read(3, "\4\374\2\374\7\0\0\0h\0\0\0\0\0\0\0@\0\0\0\0\0\0\0X\0\0\0\0\0\0\0"..., 64) = 64
close(3) = 0
write(2, "/usr/share/fonts/util: failed to"..., 45/usr/share/fonts/util: failed to write cache
) = 45

This command works for me:

sudo SOURCE_DATE_EPOCH=$(date +%s) fc-cache -rs

SOURCE_DATE_EPOCH can also be any positive integer (e.g., 1234).

It looks like it failes on directories that does not contain a .uuid file
For me this is only the case for /usr/share/fonts/encodings/large and /usr/share/fonts/utils

Likewise
(4/7) upgrading lib32-fontconfig [#######################################################] 100%
Rebuilding 32-bit fontconfig cache.../usr/share/fonts/100dpi: failed to write cache

@yan12125, that doesn't count.

> SOURCE_DATE_EPOCH is used to ensure fc-cache(1) generates files in a deterministic manner in order to support reproducible builds. When set to a numeric representation of UNIX timestamp, fontconfig will prefer this value over using the modification timestamps of the input files in order to identify which cache files require regeneration.

Depending on how you mess with the pseudo-date (try a value *greater than the current time, not less) you will indeed continue to hit the issue regardless.

What is the impact of this issue (i.e. what is the impact of not having an updated font cache) ?

Hi Florent, It seems to tie in here with Firefox's four Web Content threads grabbing much CPU for about five seconds after running fc-list(1). fc-list completes promptly. The CPU fan spins like mad, that's why I noticed. Similar behaviour happens on open a new Firefox tab, more so it seems if the page has a range of fonts. I've reported this association upstream. My pacman upgrades that triggered this were limited, so it seems connected.

I've downgraded lib32-fontconfig (1:2.13.1-1 -> 1:2.13.0+15+gc60ed9e-1) and fontconfig (1:2.13.1-1 -> 1:2.13.0+15+gc60ed9e-1) and the Firefox-fan-knackering on a new tab or fc-list has gone. There were no other changes. Perhaps users with beefier modern machines might not notice, but perhaps their battery charge will.

For me it is also not only cosmetic. My terminal (urxvt) and dmenu slowed down noticeably, from basically instant to maybe half a second. Downgrading solved this.

I can second the Firefox issue, downgrading fontconfig fixed the problem.

I can also confirm the same issue.Downgrading to the previous version solved the problem for now.

Same problem. Openbox on Archlinux.

Rebuilding fontconfig cache.../usr/share/fonts/cyrillic: failed to write cache
/usr/share/fonts/encodings/large: failed to write cache
/usr/share/fonts/misc: failed to write cache
/usr/share/fonts/util: failed to write cache
done.