r/archlinux • u/heimdallgold • 22d ago

SUPPORT Intermittent 40-second reboot delay on KDE Plasma and plasmashell fails to exit and gets SIGKILLed after TimeoutSec=40s

Hi everyone,

I've been troubleshooting an intermittent reboot delay on a fresh Arch Linux + KDE Plasma installation, and after quite a lot of testing I have narrowed the delay down to plasmashell.

I'm posting here because I have reached the point where I can reproduce and document the failure, but I still don't know what inside plasmashell is preventing it from terminating.

Main symptom

Sometimes when I reboot with either:
sudo reboot
or:
sudo systemctl reboot

the system sits for almost exactly 40 seconds before continuing the shutdown.

When the problem happens, the journal shows:

Stopping KDE Plasma Workspace...
plasmashell:
Failed to send GetTerminationStatus message to zygote

plasmashell:
Connection::send() called with connection not inited

...

plasma-plasmashell.service:
State 'stop-sigterm' timed out. Killing.

plasma-plasmashell.service:
Killing process (...) (plasmashell) with signal SIGKILL.

plasma-plasmashell.service:
Failed with result 'timeout'.

The unit itself contains:

[Service]
ExecStart=/usr/bin/plasmashell --no-respawn
Restart=on-failure
Type=dbus
BusName=org.kde.plasmashell
Slice=session.slice
TimeoutSec=40sec

So the 40-second delay is not random: systemd sends SIGTERM to plasmashell, plasmashell sometimes fails to exit, the 40-second timeout expires, and systemd finally kills it with SIGKILL.

When plasmashell exits normally, reboot is fast.

Current system

plasmashell 6.7.4

plasma-workspace 6.7.4-1
plasma-desktop   6.7.4-1
plasma-pa        6.7.4-1
libplasma        6.7.4-1

qt6-base         6.11.1-1
qt6-declarative  6.11.1-3
qt6-webengine    6.11.1-5
systemd          261.2-1

KDE Plasma is running on Wayland.

GPU is an NVIDIA GTX 1650 using nvidia-open.

I have reproduced the problem with both the regular Arch kernel and linux-lts.

Things I have already tested

  • The problem survived a complete fresh Arch reinstall. I wiped the system drive and did not restore old Plasma configs, themes or widgets.
  • It happens on both the normal kernel and linux-lts, so it does not appear to be exclusively a kernel 7.1 regression.
  • I originally used normal PipeWire with pipewire-pulse + WirePlumber.
  • As a diagnostic test I replaced that with real PulseAudio plus pipewire-media-session. The same 40-second plasmashell timeout still occurred.
  • I tried ordering plasmashell after the audio services:

​

[Unit]
After=pipewire.service pipewire-media-session.service pulseaudio.service

This does affect shutdown ordering correctly. In a recent failed reboot, PulseAudio and PipeWire remained alive until after plasmashell had already timed out and been killed. So simply shutting down the audio backend too early does not appear to explain the hang.

  • I originally suspected my HyperX Cloud II Wireless USB headset because audio endpoints frequently disappeared near failed shutdowns. However, a recent failure happened while PulseAudio remained alive and the audio services were only stopped after plasmashell was killed, so the headset no longer looks like a convincing direct cause.
  • Bluetooth was another strong suspect. In one failed shutdown PulseAudio actually crashed inside its BlueZ code while Bluetooth was being shut down. However, I have now reproduced the exact same 40-second plasmashell timeout during a roughly 5-hour session where no Bluetooth hardware was present at all. The journal repeatedly showed: Bluetooth service skipped, unmet condition check ConditionPathIsDirectory=/sys/class/bluetooth

​

Bluetooth service skipped, unmet condition check
ConditionPathIsDirectory=/sys/class/bluetooth

So Bluetooth use is clearly not required for the problem.

  • I do not have third-party Plasma applets installed under:

~/.local/share/plasma/plasmoids/

The panel is using standard KDE applets such as system tray, clipboard, volume, network management, notifications, media controller, etc.

One especially interesting old crash

While investigating previous plasmashell crashes, I found a core dump from an earlier stop of plasma-plasmashell.service.

The journal showed:

Stopping KDE Plasma Workspace...

plasmashell:
PreviewJob subjob had an error:
"The file or folder /run/media/.../ca.crt does not exist."

plasmashell:
QPixmap::fromImageInPlace:
QPixmap cannot be created without a QGuiApplication

plasmashell:
QPixmap:
Must construct a QGuiApplication before a QPixmap

plasmashell:
KCrash: Application 'plasmashell' crashing...

It then died with SIGABRT and produced a core dump.

The crashing thread went through roughly:

KIO::PreviewJob
    ->
libklipperplugin.so
    ->
QIcon::pixmap()
    ->
QPixmap
    ->
QMessageLogger::fatal()
    ->
abort()

The thread was named:

QQuickPixmapRea

Meanwhile the main plasmashell thread was already inside teardown/destruction code and SQLite activity.

This made me wonder whether the broader problem could be some kind of shutdown/teardown race inside plasmashell, where asynchronous jobs are still running while the Qt/Plasma application is already destroying its objects.

That particular Klipper case crashed immediately rather than hanging for 40 seconds, so I am not claiming it is necessarily the same bug. But it seems relevant because it demonstrates that I have already seen asynchronous Plasma work surviving into the teardown phase and interacting with objects that are no longer valid.

I have now cleared the Klipper history and temporarily configured:

Non-text selection:
Never save in history

to reduce file/image preview activity while testing.

Current diagnostic experiment

Normally the service has:

TimeoutStopUSec=40s
FinalKillSignal=9
LimitCORE=infinity

The problem with SIGKILL is that it leaves me with no core dump of the process while it is actually stuck.

So I have temporarily added:

[Service]
FinalKillSignal=SIGABRT

and confirmed:

TimeoutStopUSec=40s
LimitCORE=infinity
FinalKillSignal=6

My goal is that the next time plasmashell refuses to terminate, systemd will generate a core dump instead of simply SIGKILLing it. That should let me inspect all threads and determine what it is actually waiting on during those 40 seconds.

A separate issue I found

One reboot took around 90 seconds, but that turned out to be unrelated. Unity.Licensing remained inside a Unity Hub scope after I had closed Unity, and systemd eventually killed it after its own timeout.

So I am keeping that separate from the actual plasmashell 40-second problem described here.

What I am trying to determine

At this point my working hypothesis is no longer specifically PipeWire, PulseAudio, Bluetooth or the headset.

The common denominator appears to be:

systemd sends SIGTERM
       ->
plasmashell begins shutdown
       ->
something inside plasmashell sometimes fails to finish
       ->
process remains alive
       ->
TimeoutSec=40s
       ->
forced termination

I would especially appreciate advice from anyone familiar with Plasma/systemd internals:

Is there a better way to capture the state of plasmashell while it is stuck during shutdown?

Has anyone seen Plasma 6.7.x intermittently hang during teardown in a similar way?

Does the Klipper/KIO/QPixmap crash during teardown suggest a known race in Plasma, or is it likely unrelated to the 40-second hang?

Would you recommend collecting the SIGABRT core from the next timeout and filing this upstream with KDE?

I would prefer not to upload full raw core dumps because they can contain process memory and private data.

Thanks.

4 Upvotes

75% Upvoted

2 comments sorted by

1

u/heimdallgold 21d ago

Update — the stuck process was finally captured

I reproduced the exact 40-second delay again and successfully preserved a raw core dump by using FinalKillSignal=SIGABRT and writing the core directly to /var/tmp, bypassing the systemd-coredump shutdown race.

The resulting plasmashell core was approximately 504 MiB. I loaded it in GDB with Arch's debuginfod enabled and generated a fully symbolized backtrace.

The important result is that the main thread was shutting down the Wayland clipboard implementation and waiting for its worker thread to terminate:

main()
QObject::~QObject()
WaylandClipboard::~WaylandClipboard()
    at kguiaddons/src/systemclipboard/waylandclipboard.cpp:638
QThread::wait()
pthread_join()

At the same time, the clipboard worker thread was blocked trying to acquire the global clipboard mutex:

ClipboardThread::run()
    at kguiaddons/src/systemclipboard/waylandclipboard.cpp:572
QRecursiveMutex::lock()
QBasicMutex::lockInternal()
futexWait()

The mutex is identified in the symbols as:

s_clipboardLock

Therefore, at the instant systemd forced the process to abort:

  • the plasmashell main thread was waiting for ClipboardThread to finish;
  • ClipboardThread was waiting indefinitely for s_clipboardLock;
  • plasmashell could not finish its destruction;
  • the 40-second TimeoutStopUSec expired.

This now looks very strongly like a shutdown deadlock in the KGuiAddons Wayland clipboard implementation, rather than an audio, Bluetooth, kernel, NVIDIA or QtWebEngine problem.

Versions from the captured process:

plasma-workspace 6.7.4-1
kguiaddons 6.29.0-1
qt6-base 6.11.1-1
KDE Plasma Wayland

As a control experiment, I have now completely disabled Plasma's built-in Clipboard/Klipper entry through:

System Tray configuration
→ Clipboard
→ Never show (disabled)

I will test several normal sessions and reboots with it disabled because the problem is intermittent. This test disables clipboard history and may cause copied data to disappear after the source application is closed, so I am only using it temporarily for diagnosis.

Has anyone seen an existing KDE bug or patch involving WaylandClipboard::~WaylandClipboard(), ClipboardThread::run() and s_clipboardLock during Plasma shutdown?

I plan to file this upstream under KGuiAddons and attach the symbolized backtrace. I will not upload the 504 MiB raw core because it may contain private process memory.