xfsettingsd(xfce4-settings) cause the pc freeze every two or three seconds

Hello everyone .Im new to this forum and my destination to been here to find if someone can help me solve the problem .
The problem is after latest update (more info I will provide down below) .After logged in through the login gui .my pc is seem to be normal untill next 5 second the cpu usage start to increase then drop and repeated every 2 or 3 second .to stop this .I need to

Code:

---

killall xfsettingsd

---

(I run as root normally)in terminal(I can do in the tty and xfce4-Terminal)

high CPU load caused by xfsettingsd seem to affect to made other xfce's program use high load too .That are very weird.

I will provide some of my spec and os information .other stuff will on next post .

PC : Netbook
Brand : Samsung
CPU :Intel Atom N550 @1.5 GHz
Architecture:x86_64
Ram:Hynix 2gb 1333 DDR3
HDD:Seagate 500gb

Kali
Cat /proc/version gave me this

Code:

---

Linux version 4.18.0-kali2-amd64 ([email protected]) (gcc version 7.3.0  (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2kali1 (2018-10-09)

---

Release : kali-rolling
Codename : kali-rolling
xfce4-settings version(downgraded) :4.12.0
-0ubuntu1 (installes through .deb package)
xfce4 version : 4.12.4
xfwm4 version : 4.12.5-1

If need More imformation.just tell me (sory for no logging .I can't really find ).

The issue seems to be related to fontconfig/libfontconfig1 but if you downgrade them, they'll fail to install because the previous version had issues with empty folders.

Probably better to open a bug on bugs.kali.org (i don't believe there is one)

I was having the exact same issue. It would freeze every 3-5 seconds. Then I tried to unistall X11 and xfce4 and I've reinstalled both of them and now this is happening: https://forums.kali.org/showthread.p...kali2-686-pae)

Since I recently installed Kali Linux 2018-4, I also have been experiencing this issue. After some searches on the web and my own observations, I realized that fontconfig is repeatedly creating font cache at /var/cache/fontconfig. You can see the size of that directory grows.
# watch 'du /var/cache/fontconfig'

After some more diggings, xfsettingsd seems to be the one making fontconfig to do so. When xfsettings is running, timestamps of some subfolders in /usr/share/fonts keep changing. For instance,
# watch 'ls --full-time /usr/share/fonts'
# watch 'ls --full-time /usr/share/fonts/X11'
That in turns causes fontconfig to be notified and create new font cache. Once xfsettingsd is killed, those timestamps cease changing and no more font cache created.

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.

Hopefully someone can soon devise a patch for this issue. So far I stop xfsettingsd from running as the workaround.

It appears to be the interaction between xfsettingsd and fontconfig that causes this issue. Fontconfig (2.13.1) removes .uuid file from any directories containing no fonts after scanning it. That action changes the modification time of those folders. Because xfsettingsd monitors those font directories, it gets notified when their modification time changed and in turn notifies fontconfig to rescan them. So the cycle begins.

A patch has been commited to the master branch of fontconfig so that it doesn't delete .uuid file in directories lacking font files. See https://gitlab.freedesktop.org/fontc...b8f616b6390ad4 That should solve the problem, I think. But, so far there is no binary released.