fontconfig and xfsettingsd (not a call for help, rather experience feedback, for those interested)

Hi all,

For a while now (8 months or so), my system was sporadically hogged by high iowait and a very high load. Sometimes, this was at random, sometimes this was after I launched an electron app.
The drives and the memory are fine, so this had to come from somewhere else. I quickly found out that fontconfig was (one of) the culprit(s), but I couldn't quite point out were the problem was. Until I stumbled upon this post and this post. To summarize, the users noticed that killing xfsettingsd would remedy the problem. This aligns pretty well with my problem because:

  • Only Xorg was plagued by this problem and would become unresponsive, I could still use the tty,
  • Killing the X server would sometimes remedy the problem,
  • Indeed, killing xfsettingsd would remedy the problem, too.
    Furthermore, the first post states that:

Xfsettingsd uses g_file_monitor() calls to monitor those font folders, and runs a call-back function to notify fontconfig when any of those folders are modified. Since those timestamps keep changing, fontconfig constantly gets notified and creates more font cache. That severely impacts system performance, especially for GUI programs need to render texts on the screen.

This is reminiscent of some errors that I found running journalctl -r | grep -i Fontconfig among whose output I could find, for example:

org.xfce.ScreenSaver[1645]: Fontconfig warning: Directory/file mtime in the future. New fonts may not be detected.

A patch has been submitted a while ago to solve this problem. I don't know whether that does the trick or not, but, in any case, I noticed that the fontconfig and lib32-fontconfig from the arch repositories are much more recent than the ones in the manjaro repositories (which are of version 2:2.13.1+12+g5f5ec56-1 versus 2:2.13.91+24+g75eadca-2 for Arch). I did find a 2.13.91 version in the AUR (2:2.13.91+18+g01e4f08-1, fontconfig-git and lib32-fontconfig-git) which, so far, seem to solve the problem without having to kill xfsettingsd.

This is not ideal, as these are AUR packages, but it still is better than a situation were my machine would become unusuable for 10 - 15 min at random.

Edit: removing xfce4-screensaver and reinstalling fontconfig and lib32-fontconfig from the repos, I didn't observe the high iowait seen when xfce4-screensaver was on the system (I got the clue by the fact that xfce4-screensaver isn't on the live image). However, launching electron apps (atomic-tweetdeck and open-vector-editor) led to high iowait again and the system stalling. This behaviour was already present before I replace fontconfig and lib32-fontconfig(from the repos) with fontconfig-git and lib32-fontconfig-git, respectively. I don't know whether anyone else experienced that, though.

that arch repo +24 package is from january. i don't know why it wouldn't have been automatically pulled into unstable back then. @philm, is it excluded for some reason?

Yes, and it is flagged out of date.

that is true, but that's not relevant to the version that's in arch's repo currently being pulled to manjaro unstable.

Sure. I was mainly pointing out that some new build will find their way into the arch repos soon.

It is possible that what I noticed above and this are related.

One thing I remembered is that versions newer that the one in the repo break the font rendering on the snap store. I don't use it, so had to try and that's indeed the case.

That said, downgrading to the fontconfig version from the repos, rebuilding the cache (sudo fc-cache -rsv) and doing a sudo rm -v /var/cache/fontconfig/*as advised by @philm didn't work on the snapstore.

So between to evils, I gotta choose the least and go with the fontconfig-git versions for the time being.

TL;DR {

pkill xfsettingsd
     fc-cache --verbose --really-force
sudo fc-cache --verbose --really-force --system-only
xfsettingsd --replace

} TL;DR


I also admit that there is a problem between xfsettingsd and fontconfig. Just run:

XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon

and later on when the problem occur you will notice the endless font cache refresh cycle.

To break that cycle ad-hoc, just kill the xfsettingsd. Sometimes, in rare situations, you might notice that there are two xfsettingsd processes run, kill all of them (pkill xfsettingsd).

Refresh font cache manually:

     fc-cache --verbose --really-force
sudo fc-cache --verbose --really-force --system-only

and run xfsettingsd again by running one of these:

                    xfsettingsd --replace
XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon

Thanks. I did some of that already without noticing any improvement (rebuild the cache while xfsettingsd is or is not running). For the sake of being thorough, I went back to the versions in the repos and I implemented your suggestion. Doing that, I still do have a high load at session startup (comparable to what I had before switching to fontconfig-git, ~14 vs 2.5) which fades after a while. The fact that I had it before and that these cycles crept on me once in a while let me think that it would happen again. No patience to wait it out, though, so I launched an electron-based app, which would cause the system to stall with fontconfig from the repos. Indeed, this happened again, as some of these apps are needed for my work, I decided to go back to the fontconfig-git and lib32-fontconfig-git from the AUR…
I guess I just have to wait for Manjaro to pull the versions from arch before using the repos again.

You are right. I haven't provided a permanent solution. Commands I use just helps me when the problem occur - high CPU load but what worry me more, unnecessary SSD disk wear. There are just some occasions when directories with fonts are updated for me (for example during package installation or upgrade), so it is good to kill xfsettingsd before doing that and run it after to not let it triggers hundreds calls to fontconfig:

...
xfce4-settings(fontconfig): monitoring 1389 paths
xfce4-settings(fontconfig): timestamp updated (time=1592225392)
xfce4-settings(xsettings): 34 settings changed (serial=28, len=1308)
xfce4-settings(fontconfig): monitoring 1389 paths
xfce4-settings(fontconfig): timestamp updated (time=1592225396)
xfce4-settings(xsettings): 34 settings changed (serial=29, len=1308)
xfce4-settings(fontconfig): monitoring 1389 paths
xfce4-settings(fontconfig): timestamp updated (time=1592225400)
xfce4-settings(xsettings): 34 settings changed (serial=30, len=1308)
xfce4-settings(fontconfig): monitoring 1389 paths
xfce4-settings(fontconfig): timestamp updated (time=1592225404)
xfce4-settings(xsettings): 34 settings changed (serial=31, len=1308)
...

I will just wait until Manjaro team update fontconfig package that hopefully will solve the issue.
I just wonder what is the cause that the problem is more frequent for you...

1 Like

Hi,
No problem, it was worth a try anyway.

With me, the problem is not that frequent, there can be days between occurrences. Besides the time that you cites, xfsettingsd updates directory timestamp sometimes, without me installing or upgrading packages, like with electron apps, probably due to another package install (I haven't looked into that in detail); but for me, the fact that it can occur seemingly at random is more annoying, especially if it happens in the middle of some work. That's the rationale behind me installing the aur versions.

Anyway, fontconfig 2.13.91 from arch is in the unstable repos, so it may come to testing and stable soon.

Happy to report that the update from fontconfig 2:2.13.1+12+g5f5ec56-1 to fontconfig 2:2.13.91+24+g75eadca-2 in testing solves this problem.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by