WebKitWebProcess uses 100% of one CPU core on Zorin OS 18.1 – fontconfig cache workaround

Tutorials & Guides
1 
Hello,

I would like to share a `WebKitWebProcess` high CPU problem that I reproduced and fixed on **Zorin OS 18.1**.

After starting the computer, one logical CPU core remained at **100% usage indefinitely**. In GNOME System Monitor, the process responsible was:

`WebKitWebProcess`

On my system with 20 logical CPUs, the process showed approximately 5% total CPU usage, while one individual logical CPU was continuously running at 100%.

## Identifying the parent application

I checked which application started the process:

```bash
p=$(pgrep -n -f '[W]ebKitWebProcess')
echo "PID WebKitWebProcess: $p"
pstree -aps "$p"

The relevant part of the output was:

systemd
 └─ gnome-session
     └─ portmaster
         └─ WebKitWebProcess

I then tested this directly:

  • after closing Portmaster, WebKitWebProcess disappeared and the 100% CPU usage stopped;
  • after starting Portmaster again, WebKitWebProcess appeared again and one CPU core immediately returned to 100%.

So Portmaster was definitely the application whose WebKit process triggered the high CPU condition on this system.

However, I do not know which application originally created the problematic fontconfig cache described below. Therefore I am not claiming that Portmaster itself created the cache problem.

Installed versions

The relevant packages on my Zorin OS 18.1 installation are:

fontconfig 2.15.0-1.1ubuntu2
libfontconfig1 2.15.0-1.1ubuntu2
libwebkit2gtk-4.1-0 2.52.6-0ubuntu0.24.04.1

Google Chrome is not installed on this computer. Chromium is installed.

Checking the user fontconfig cache

I checked for symbolic links in the user fontconfig cache:

find ~/.cache/fontconfig -maxdepth 1 -type l -printf '%f -> %l\n'

There were many links following this pattern:

*-le64.cache-9  -> *-le64.cache-12
*-le64.cache-10 -> *-le64.cache-12
*-le64.cache-11 -> *-le64.cache-12

Workaround that fixed the problem

I terminated the running WebKitWebProcess processes using the full process name:

pkill -f '[W]ebKitWebProcess'

I then removed only symbolic links from the user fontconfig cache and rebuilt the font cache:

find ~/.cache/fontconfig -type l -delete
fc-cache -f

I checked the cache again:

find ~/.cache/fontconfig -maxdepth 1 -type l -printf '%f -> %l\n'

There was no output.

I then rebooted the computer.

Result after reboot

After reboot:

  • Portmaster started and worked normally;
  • WebKitWebProcess was still present, as expected;
  • its CPU usage was approximately 0.03% while idle;
  • no logical CPU remained at 100%;
  • the problematic symbolic links had not returned.

The same check:

find ~/.cache/fontconfig -maxdepth 1 -type l -printf '%f -> %l\n'

again produced no output.

So on this system, removing the symbolic links from ~/.cache/fontconfig and rebuilding the font cache completely resolved the persistent WebKitWebProcess CPU load, including after a reboot.

Important note

I would not consider this a universal fix for every case where WebKitWebProcess uses a lot of CPU.

Before applying the workaround, I recommend checking whether the affected system actually contains the same cache-9 , cache-10 or cache-11 symbolic links pointing to cache-12 .

If those links are not present, the high CPU usage may have a different cause.

I also did not determine which application originally created the cache-12 files and compatibility symbolic links on my system.

Related upstream reports

This appears to be related to the recently reported Ubuntu/WebKitGTK/fontconfig issue:

I am posting my result because this reproduces the same general symptom on Zorin OS 18.1 , but in my case the affected application was Portmaster , and Google Chrome is not installed .

I hope this may help other Zorin OS users who encounter the same WebKitWebProcess high CPU problem.

12 Likes
2

Well done to you for solving this issue.

But ... isn't it extremely sad that pushing something new out without giving users the opportunity to stay with what works and works well? (SysV Init, ALSA, APT, X11/xorg)

3

If I understand correctly, this problem can be triggered by any Chromium-based browser which uses a similar version as google chrome 154. It's also possible that the problematic links or files are created again and again as soon as you start using the browser.

4

Thank you. In this case, however, the issue seems to be specifically related to the interaction between the fontconfig cache and WebKitGTK. My intention with this topic was mainly to document the reproducible problem and the workaround that worked on Zorin OS 18.1.

1 Like
5

Thank you. I tested this on my system because Chromium is installed here, while Google Chrome is not.

I started Chromium several times, opened multiple websites, closed it, started it again and repeated the test.

The problematic fontconfig symlinks were not recreated. I then performed another full reboot of the computer.

After reboot, Portmaster started normally, WebKitWebProcess is running at about 0.03% CPU, no logical CPU core is stuck at 100%, and another check of ~/.cache/fontconfig still showed no symbolic links.

So at least with the Chromium version installed on my Zorin OS 18.1 system, simply starting and using Chromium does not reproduce the problem or recreate the problematic cache symlinks.

I agree, however, that the links could potentially be recreated later by whichever application originally created them. I still have not identified that application.

3 Likes
6

For me this issue caused Evolution and Geary (Epiphany as well) to use much of my CPU and none of my mails/websites would render. Looking at top it was also the webkit process sitting on 100% on one of my cores.
Following the steps you provided solved this.
Thank you so much :slight_smile:

4 Likes
7

Thank you soooo much Miroslav !
I encountered the same issue running MMEX Money Manager, and could not figure out what was happening besides the fact that WebKitWebProcess was using 100% of one of my CPUs.
I did what you recommended and it worked like a charm.

Thanks again :slight_smile: