Systemd user service sporadically uses 100% of one CPU core - possibly Gnome-related

Support
1

For about the past month, the “/usr/lib/systemd/systemd --user” process on my system will intermittently spike to 8% total CPU usage, ie it’s maxing out 1 of my 12 cores (Intel i7-8700). RAM, disk I/O, and network are not being taxed when this happens. GPU utilization and VRAM are also not being taxed, according to the nvidia control panel. I’m having trouble tracking down why this is happening.

One thing I’ve noticed is that when it’s in this state, opening a new gnome-terminal window takes a weirdly long time - the window appears, but isn’t interactive and the prompt doesn’t appear until after several seconds.

This happens intermittently enough that i can’t tell what triggers it. It starts doing it randomly, can last for minutes or an hour, then stops just as suddenly. It’s just as likely to happen while I’m away, and I come back to find the core spiked, as when i’m in the middle of doing something on the machine. It happens regardless of what programs I’m actively running.

Checking journalctl, I see a bunch of warnings related to Gnome Shell and various extensions I’m running - hence why I posted this in the Gnome subforum - but as I’m unused to poring over journalctl’s output I can’t tell which one (if any) might be causing the issue. I’ve tried disabling all extensions, and the problem seemed to go away (but because it’s so sporadic, hard to say if it really did?). I tried re-enabling extensions one by one, to see if i could find one that started the issue, but I got different results on different sessions :[

I tried searching for several variations on “systemd high CPU”, “gnome shell extension high cpu”, anything else I could think of, and found nothing that seemed like it described the problem I’m seeing.

Like I said, this started happening over a month ago - my best guess (it took me a while to notice it was happening) was after the June 12th Stable update.

software: manjaro stable branch (Gnome 42.3, kernel 5.18.12-3, Pipewire 0.3.56-1)
hardware: Nvidia GTX 1070 (latest binary drivers) on X11, 32GB RAM

2

I suppose a list of extensions installed and active would be helpful:

  • AlternateTab
  • AppIndicator and KStatusNotifierItem Support (from official repositories)
  • Caffeine
  • Dash to Dock (from official repositories)
  • Dynamic Panel Transparency (from AUR)
  • Impatience
  • Native Window Placement
  • OpenWeather
  • Removable Drive Menu
  • Sound Input & Output Device Chooser
  • system-monitor-next
  • Workspace Scroll
3

I am currently aware of a problem with similar symptoms: Wireplumber

4

I see a wireplumber process running, but it’s using close-to-zero CPU. Is that issue related to the systemd --user process?

5

Okay, I managed to catch some strace -p 1438 (the PID of the systemd --user process) output while the high CPU usage was happening… I have no idea if this is useful info but the output was flying by with tons of this line:

epoll_wait(4, [{events=EPOLLIN, data={u32=1832395584, u64=93898407420736}}], 138, 0) = 1
recvmsg(36, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\0\0\0\0\300z\0\0\277\0\0\0\1\1o\0K\0\0\0", iov_len=24}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 24
recvmsg(36, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="/org/freedesktop/systemd1/unit/d"..., iov_len=184}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_CMSG_CLOEXEC) = 184
sendmsg(36, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\341A\0\0\213\314\6\0\37\0\0\0\5\1u\0\300z\0\0\6\1s\0\6\0\0\0"..., iov_len=48}, {iov_base="\334A\0\0<!DOCTYPE node PUBLIC \"-//fr"..., iov_len=16865}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 16913
6

i mean whatever that is, it looks like your theme/theme extension is bugging out. at the very end of the bottom command you can see it tried to ‘transmit a message to a socket’ and didnt get a signal back? soo, i mean it sounds like it would be easier to just go back to default themes and everything and enable stuff one by one and see what breaks it. but idk i havent seen any other advice. Probably easier than finding the actual bug. looks like u already did that. i would say do it again and actually wait longer to clarify your results. Sounds like you were a bit impatient.
edit: i googled some random things. looks like the d-bus interface of systemd is trying to interact with whatever unit that is…the ‘input output value base’ says something about a node Doctype. idk im just googling.

7

I’m now ~90% sure this is indeed a Gnome issue; I installed XFCE and let it run for most of the day and didn’t see this issue even once.

I’m going to be a bit more systematic about this: I’ve uninstalled every Gnome Shell extension I had active and will wait a day or two before reinstalling each one in succession, confirming that the issue didn’t suddenly start happening again.

What’s been most frustrating about troubleshooting this issue thus far is how much of a black box systemd seems to be as far as monitoring the performance of each of the services it runs. With a program like systemdgenie you can see a list of all the services (and devices, etc etc) active and what their status is, but it’s very different from a process manager type situation where you can get each process’s resource usage, files it’s accessing, etc.
Probably the weirdest thing is that when I open systemdgenie and start poking around, the program hangs, and systemd’s CPU usage spikes! Sometimes it’ll recover and sometimes I’ll have to kill it manually. I have no idea how to troubleshoot this, what could possibly be causing it, and why it is unique to my system - my install is about 2.5 years old but it’s pretty off-the-shelf, I’ve never used a custom kernel or mucked around with any low level OS internals.

8

I might have narrowed it down: after reinstalling Dash to Dock, system-monitor-next, and Workspace Scroll, one each day, with no CPU usage issues, this morning when I reinstalled “AppIndicator and KStatusNotifierItem Support” I saw the issue occur within an hour or two. Uninstalling it and rebooting and the issue hasn’t been back since. I’m going to open an issue with the extension in question and see if they know why this might be happening.

9

Hi

I had the same issue and solved it by setting 2 variables in these files:
/etc/systemd user.conf and system.conf

Changed:
LogLevel=info to LogLevel=err
and DefaultLimitCPU=50%

CPU limit was blank and commented out.
After this change, ‘systemd init’ and ‘systemd -user’ processes does not even register.

Another symptom I had was file-browser (dolphin) will go stale on ‘refresh’, slowing down basic file browsing tremendously.

1 Like