xfsettingsd hangs periodically after upgrade to Fedora 29

polemon · 2018-11-05 18:07:41

After upgrading from Fedora 28 to Fedora 29, I'm faced with a rather annoying bug (?), which renders XFCE next to impossible to use.

When starting XFCE, xfsettingsd runs in the background. Whenever xfce4-terminal or roxterm is opened, xfsettingsd starts behaving rather curiously. It periodically hangs the rest of the desktop, ramping up the load to around 50 (normal load while idling is ~0.05).
These periodical hangs come about around once every five seconds and last around a half to one second, in which no keyboard input is processed, no mouse input, and all displays freeze. This essentially renders the desktop environment unusable.

A quick remedy to this, is to kill xfsettingsd. However, by doing that I use a bunch of desktop functionality, for instance my keyboard shortcuts to open a Terminal stop working, etc.

Restarting xfsettingsd, makes all instances of xfce4-terminal segfault, should they be running, same thing for roxterm. If no instance of those terminal emulators are running, xfsettingsd seems to be alright, however launching the terminal emulators once, makes xfsettingsd go into that weird resource-hogging behavior again.

For reference, I'm using version 4.13.5 (Xfce 4.12) of xfsettingsd.

uname -r is: 4.18.16-300.fc29.x86_64

/etc/fedora-release is: Fedora release 29 (Twenty Nine)

I'd very much like to solve this issue, because it seriously impedes with me being able to use my XFCE desktop.

ToZ · 2018-11-05 18:21:43

Hello and welcome.

Can you post back your current x settings:

xfconf-query -c xsettings -lv

Also, try running xfsettings in verbose mode to see if any error messages display in the terminal window:

xfsettingsd --no-daemon --replace

Long shot suggestion: delete the contents of ~/.cache/settings before logging in.

Does fedora have an ~/.xsession-errors file? If so, can you post the contents?

polemon · 2018-11-05 22:28:39

Here's what xfconf-query -c xsettings -lv prints:

/Gdk/WindowScalingFactor        1
/Gtk/ButtonImages               true
/Gtk/CanChangeAccels            false
/Gtk/ColorPalette               black:white:gray50:red:purple:blue:light blue:green:yellow:orange:lavender:brown:goldenrod4:dodger blue:pink:light green:gray10:gray30:gray75:gray90
/Gtk/CursorThemeName            
/Gtk/CursorThemeSize            0
/Gtk/DecorationLayout           menu:minimize,maximize,close
/Gtk/FontName                   Sans 10
/Gtk/IconSizes                  
/Gtk/KeyThemeName               
/Gtk/MenuBarAccel               F10
/Gtk/MenuImages                 true
/Gtk/MonospaceFontName          Monospace 10
/Gtk/ToolbarIconSize            3
/Gtk/ToolbarStyle               icons
/Net/CursorBlink                true
/Net/CursorBlinkTime            1200
/Net/DndDragThreshold           8
/Net/DoubleClickDistance        5
/Net/DoubleClickTime            400
/Net/EnableEventSounds          false
/Net/EnableInputFeedbackSounds  false
/Net/IconThemeName              Adwaita
/Net/SoundThemeName             default
/Net/ThemeName                  Adwaita
/Xft/Antialias                  1
/Xft/Hinting                    -1
/Xft/HintStyle                  hintfull
/Xft/RGBA                       rgb

Right after running xfsettingsd --no-daemon --replace, I get this:

(xfsettingsd:14824): xfsettingsd-WARNING **: 23:15:59.725: Property "/Gdk/WindowScalingFactor" has an unsupported type "guint".

xfsettingsd runs fine as long as I don't open a xfce4-terminal, if I do, no errors are printed and this resource hogging starts again.
Control-C makes xfsettingsd fork into the background, and ps aux | grep xfsettingsd makes it show up as:

xfsettingsd --no-daemon --replace --display :1.0 --sm-client-id 217267af2-a209-4e74-8999-719801a54a4c

It then resumes normal operation. If I then start another xfce4-terminal, the whole shenanigans begin anew, and I must kill xfsettingsd, to get rid of those lock-ups.

~/.xsession-errors does not exist.

I've cleared ~/.xfce4-session.verbose-log, run the entire test: no entries.

The directory ~/.cache/settings doesn't exist.

ToZ · 2018-11-06 02:31:11

polemon wrote:

The directory ~/.cache/settings doesn't exist.

Sorry, I meant ~/.cache/sessions. Try that first and see if it helps.

Does the same happen with xterm or gnome-terminal?

polemon · 2018-11-06 05:28:37

it also does happen with gnome-terminal, but not xterm. I'll see if clearing ~/.cache/sessions does anything.

polemon · 2018-11-06 07:30:06

ok, I've cleared ~/.cache/sessions, before logging in (having logged out before), no change.

ozjd · 2018-11-06 08:05:34

There will be an ~/.xsession-errors. My F29 Xfce test system in a VM has one.

polemon · 2018-11-06 19:22:32

There's none on mine. Check how old it is, perhaps it's from much earlier, if you've upgraded from one release to the other (as did I).
The file is only created when errors are experienced, otherwise, if you remove the file, and no errors are occuring, you don't have that file.

ToZ · 2018-11-06 20:42:48

Maybe try opening a bug with xfce4-terminal. Since it also affects gnome-terminal, it might be vte3 related.

polemon · 2018-11-07 06:13:06

OK, well, I'm not sure if I have enough "evidence" for a bug report, as I can't even really narrow it down... Can I perhaps check if vte3 is the culprit? I.e. anywhere I can look for error messages, or something?

Btw. in my quest to find people experiencing similar problems, I found this:
https://forums.kali.org/showthread.php? … ee-seconds

This seems to be exactly my problem. So perhaps it /is/ fontconfig related? Any ideas how to remedy that perhaps (apart from killing xfsettingsd, that is)?

Last edited by polemon (2018-11-07 07:27:05)

ToZ · 2018-11-07 12:04:33

polemon wrote:

Btw. in my quest to find people experiencing similar problems, I found this:
https://forums.kali.org/showthread.php? … ee-seconds
This seems to be exactly my problem. So perhaps it /is/ fontconfig related? Any ideas how to remedy that perhaps (apart from killing xfsettingsd, that is)?

Interesting find. It looks like a patch is going to be released soon for fontconfig. There are a number of "high cpu" and "random freeze" bug reports for xfesttingsd (https://bugzilla.xfce.org/buglist.cgi?c … lution=---) - it would be interesting if they are all related to fontconfig.

Do you have any empty font folders in /usr/share/fonts, ~/.fonts, or ~/.local/share/fonts?

I do, but I don't experience this bug (same version of xfsettingsd).

polemon · 2018-11-07 23:11:31

I do!

these are empty:

/usr/share/fonts/opensymbol
/usr/share/fonts/abattis-cantarell

I removed them and tried again. No joy. The error persists...

I'll wait for the update to land, and see if that helps the issue.

Xfce Forum

Sub domains

#1 2018-11-05 18:07:41

xfsettingsd hangs periodically after upgrade to Fedora 29

#2 2018-11-05 18:21:43

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#3 2018-11-05 22:28:39

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#4 2018-11-06 02:31:11

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#5 2018-11-06 05:28:37

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#6 2018-11-06 07:30:06

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#7 2018-11-06 08:05:34

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#8 2018-11-06 19:22:32

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#9 2018-11-06 20:42:48

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#10 2018-11-07 06:13:06

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#11 2018-11-07 12:04:33

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

#12 2018-11-07 23:11:31

Re: xfsettingsd hangs periodically after upgrade to Fedora 29

Board footer