plasma-plasmashell.service stop timeout causes ~40 second reboot delay

HenryHellsing · 2026-08-11 03:13:05

Hi,

I'm having an intermittent shutdown/reboot issue with KDE Plasma on Arch Linux.

When I run:

sudo reboot

or:

sudo systemctl reboot

the system sometimes takes about 40 seconds before rebooting.

The issue seems to happen mostly after the Plasma session has been running for a long time. Shortly after booting, reboot usually works normally.

I investigated the shutdown journal and found that plasma-plasmashell.service is timing out while stopping.

Relevant journal messages:

Stopping KDE Plasma Workspace...

plasma-plasmashell.service: State 'stop-sigterm' timed out. Killing.
Killing process (plasmashell) with signal SIGKILL.
plasma-plasmashell.service: Main process exited, code=killed, status=9/KILL
plasma-plasmashell.service: Failed with result 'timeout'.
Stopped KDE Plasma Workspace.

The timeout is consistently around 40 seconds.

The service configuration also shows:

TimeoutStopUSec=40s
KillMode=control-group
KillSignal=15
SendSIGKILL=yes

If I manually stop plasmashell before rebooting:

time systemctl --user stop plasma-plasmashell.service

it normally stops very quickly (around 0.2 seconds), and rebooting afterwards is also fast.

A KDE-coordinated reboot also works normally:

qdbus6 org.kde.Shutdown /Shutdown org.kde.Shutdown.logoutAndReboot

Using the graphical KDE "Restart" option also reboots normally.

So far, the issue seems specific to shutting down the Plasma session as part of a direct systemd reboot.

I also tested stopping PipeWire/WirePlumber before stopping plasmashell, but plasmashell still stopped normally, so PipeWire alone does not seem sufficient to reproduce the problem.

During one problematic shutdown, plasmashell logged messages such as:

PipeWire remote error: -32 connection error
context kaput
Connection::send() called with connection not inited

However, similar PipeWire messages have also appeared during normal shutdowns, so I'm not sure they are related.

I initially thought the issue had been fixed after updating Plasma and the NVIDIA driver, because several reboots worked normally. However, after using the computer for a longer session, the ~40 second timeout returned.

Current versions:

plasmashell 6.7.4
plasma-workspace 6.7.4-1
plasma-desktop 6.7.4-1
kwin 6.7.4-1
nvidia-open 610.57.04-2
nvidia-utils 610.57.04-1
linux 7.1.6.arch1-1

GPU:

NVIDIA GeForce GTX 1650

Session:

KDE Plasma / Wayland

I also checked the installed Plasma/KWin files:

sudo pacman -Qkk plasma-workspace plasma-desktop kwin

Result:

plasma-workspace: 6785 total files, 0 altered files
plasma-desktop: 4750 total files, 0 altered files
kwin: 2256 total files, 0 altered files

One additional observation: attaching GDB to plasmashell before triggering the reboot caused the reboot to complete normally in that test, so I suspect this may be timing-sensitive / a race condition.

Has anyone seen similar behavior with recent Plasma versions?

Is there a good way to determine what plasmashell is waiting for during those 40 seconds before systemd eventually sends SIGKILL?

Thanks.

seth · 2026-08-11 06:47:11

Is there a good way to determine what plasmashell is waiting for during those 40 seconds before systemd eventually sends SIGKILL?

Since it's unlikely to respond to SIGSEGV either: context.
https://bbs.archlinux.org/viewtopic.php?id=305159 was because of some kio worker (ie. likely some remote FS, network goes down while plasma is still trying to do something there) but in the end was never determined (thread is solved by "update fixed it")

HenryHellsing · 2026-08-11 16:29:12

I did another test after using the session for about 35 minutes.

time systemctl --user stop plasma-plasmashell.service

completed normally in only 0.271 seconds.
However, a direct sudo reboot after a similar amount of usage can still make the same service hit its 40 second stop timeout.

I also tested FinalKillSignal=SIGABRT. During a failed reboot systemd really sent SIGABRT:

Killing process 1160 (plasmashell) with signal SIGABRT

but the coredump could not be preserved because systemd-coredump reported:

Failed to send coredump datagram: Broken pipe

So it looks increasingly like something happening specifically during concurrent session/system teardown rather than plasmashell already being stuck before shutdown.

Also, what do you mean about context in: "Since it's unlikely to respond to SIGSEGV either: context."

seth · 2026-08-11 19:20:13

I had assumed since the process wasn't responding to sigterm it would not respond to SEGV (or ABRT for that matter) either.
Try to bypass systemd-coredump, see the blue note

So what does the context of the shutdown look like?
Do you rely on any remote FS access (ie. could it be a stalling kio thread?)

HenryHellsing · 2026-08-13 05:54:34

Unfortunately, no. I only have my PC to try to solve this problem. I've been in this for 3 days. I've been troubleshooting this problem through chatgpt and I don't even know what I'm doing. I reinstall the arch using Arch Install and the problem persist. I'm thinking this problem is related to the pipewire and some audio driver or something but I don't know. If you could help me, I would appreciate since I'm new on Arch, but I was using Mint for a while so I'm not new on Linux

seth · 2026-08-13 05:57:47

So what does the context of the shutdown look like?

In doubt please post your complete system journal for that boot:

sudo journalctl -b -1 | nc termbin.com 9999

for the previous one.

Did you manage to change the core pattern so it writes the core directly and bypasses systemd?

xerxes_ · 2026-08-13 10:16:47

What if you do just 'reboot'? Why do you need sudo?

HenryHellsing · 2026-08-13 15:48:02

I have some new results.

I reproduced the 40-second delay again on a completely fresh Arch installation made with archinstall.

I also tested simply:

reboot

without sudo, as suggested by xerxes_. It still produces the same ~40 second delay, so sudo does not seem to be relevant.

I then followed the systemd shutdown debugging procedure from the ArchWiki and booted with:

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on

This time systemd explicitly reported:

STATUS=User job KDE Plasma Workspace/stop running (5s / 40s)...
...
STATUS=User job KDE Plasma Workspace/stop running (39s / 40s)...
STATUS=User job KDE Plasma Workspace/stop running (40s / 40s)...

Immediately before the stop job starts hanging, plasmashell logs:

plasmashell: context kaput
plasmashell: No object for name "alsa_output.usb-HP__Inc_HyperX_Cloud_II_Wireless_0-00.analog-stereo"
plasmashell: No object for name "alsa_input.usb-HP__Inc_HyperX_Cloud_II_Wireless_0-00.mono-fallback"
qrc:/qt/qml/plasma/applet/org/kde/plasma/volume/main.qml:117:
TypeError: Cannot read property 'description' of undefined
kwin_wayland: PipeWire remote error: connection error
plasmashell: PipeWire remote error: -32 connection error
Connection::send() called with connection not inited

Another important result: I replaced pipewire-pulse and WirePlumber temporarily with the real PulseAudio server:

Server Name: pulseaudio
Server Version: 17.0-98-gb096

pipewire-pulse.service and pipewire-pulse.socket are no longer installed, but the same 40-second Plasma stop delay still occurs.

Therefore it does not look like pipewire-pulse or WirePlumber alone is the cause.

Manually stopping plasmashell while the session is still running remains fast:

$ time systemctl --user stop plasma-plasmashell.service

real 0m0.138s

This makes me suspect a shutdown ordering/race condition: plasmashell exits normally before system teardown, but fails to exit when the whole user session is being torn down concurrently.

Kernel in this debug run:

7.1.8-arch1-3

I do have the full debug journal. However, systemd.log_level=debug caused user database messages containing the password hash to be written to the journal, so I do not want to upload the raw file publicly. I can provide a sanitized version.

Would it make sense to check the ordering between plasma-plasmashell.service, PipeWire/PulseAudio and the other Plasma user services?

seth · 2026-08-13 16:34:49

I can provide a sanitized version.

Disable the entire debug stuff to get a clean journal and post that - and please use [code][/code] tags when posting file contents and shell IO here (you'll see why)

plasmashell: No object for name "alsa_output.usb-HP__Inc_HyperX_Cloud_II_Wireless_0-00.analog-stereo"

Have you tried to remove the headphones?

HenryHellsing · 2026-08-17 00:29:26

Hi, I have some new test results.

First, I also tested linux-lts (6.18.44-1-lts). The same ~40 second
plasma-plasmashell.service stop timeout can still be reproduced there,
so the issue does not seem to be exclusive to the 7.1 kernel series.

In my tests it appears to happen less frequently with linux-lts, but I
do not have enough samples to say that this is statistically meaningful.

I also tested a systemd user drop-in to keep the audio services ordered
before plasmashell during startup (and therefore after it during shutdown):

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

I verified that the dependencies were applied. During the next failed
shutdown, PipeWire and pipewire-media-session did in fact remain running
until after plasmashell hit its 40 second timeout:

Stopping KDE Plasma Workspace...

... about 40 seconds ...

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'.
Stopped KDE Plasma Workspace.

Stopping PipeWire Media Session Manager...
Stopped PipeWire Media Session Manager.
Stopping PipeWire Multimedia Service...
Stopped PipeWire Multimedia Service.

So keeping PipeWire alive until plasmashell exits was not enough to
prevent the timeout.

However, this failed shutdown had another important event which I had
not noticed before: PulseAudio itself crashed during shutdown.

During this ~5 hour session I had used a Bluetooth headset through a USB
Bluetooth adapter. Later I disconnected the Bluetooth adapter and went
back to using my HyperX headset, which has its own USB wireless receiver
(the HyperX itself is not Bluetooth).

At shutdown, bluetoothd started terminating and PulseAudio immediately
aborted inside its BlueZ integration:

bluetoothd: Terminating
bluetoothd: Stopping SDP server
bluetoothd: Exit

pulseaudio:
Assertion 'pa_atomic_load(&(y)->_ref) > 0' failed at
../pulseaudio/src/modules/bluetooth/bluez5-util.c:2207,
function pa_bluetooth_discovery_hook(). Aborting.

pulseaudio.service:
Main process exited, code=dumped, status=6/ABRT

pulseaudio.service:
Failed with result 'core-dump'.

Immediately after that, Plasma lost its audio objects:

plasmashell: context kaput

plasmashell:
No object for name
"alsa_output.usb-HP__Inc_HyperX_Cloud_II_Wireless_0-00.analog-stereo"

plasmashell:
No object for name
"alsa_input.usb-HP__Inc_HyperX_Cloud_II_Wireless_0-00.mono-fallback"

qrc:/qt/qml/plasma/applet/org/kde/plasma/volume/main.qml:117:
TypeError: Cannot read property 'description' of undefined

Then plasmashell started stopping and remained stuck until systemd killed
it 40 seconds later.

This makes me wonder whether, at least in this particular occurrence,
the "No object for name HyperX..." messages are a consequence of the
PulseAudio server crashing rather than the HyperX USB device itself being
the original cause.

There is also a Bluetooth-related clue from earlier in that same session:
when the Bluetooth device disappeared, both kded6 and plasmashell logged
that a bluez_sink object no longer existed. The desktop continued working
normally afterwards.

As a control test, I then used the system for about 3 hours without using
Bluetooth at all and ran:

sudo reboot

That reboot completed normally with no 40 second delay.

I need to repeat this several more times before drawing any conclusion,
but Bluetooth / BlueZ / hot-unplug now looks like a possible trigger for
at least some occurrences.

One important caveat: I have previously reproduced the same 40 second
plasmashell timeout while using pipewire-pulse + WirePlumber instead of
the real PulseAudio server. Therefore the PulseAudio assertion above
cannot by itself explain the entire history of the issue.

At this point my observations are roughly:

- the issue reproduces on both linux and linux-lts;
- manually stopping plasma-plasmashell.service before shutdown is fast;
- keeping PipeWire alive until after plasmashell stops does not eliminate
the timeout;
- in this latest failed shutdown, PulseAudio crashed in
pa_bluetooth_discovery_hook() immediately before Plasma lost the audio
objects and plasmashell became stuck;
- a subsequent ~3 hour session with no Bluetooth use rebooted normally.

Would the PulseAudio assertion in bluez5-util.c be useful for narrowing
this down further?

I can also post a sanitized clean journal from this failed boot if that
would help.

HenryHellsing · 2026-08-21 00:17:04

I finally managed to capture the actual state of `plasmashell` during the 40-second stop timeout.

I used `FinalKillSignal=SIGABRT` and configured the core to be written directly to `/var/tmp`, bypassing `systemd-coredump` during shutdown. This produced a 504 MiB raw core from the stuck `plasmashell` process.

I loaded it in GDB with Arch's debuginfod enabled. The symbolized backtrace changes the direction of the investigation.

The main thread was inside the destruction of the KGuiAddons Wayland clipboard and waiting for its worker thread to terminate:

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

Meanwhile, the clipboard worker thread was blocked on the global clipboard mutex:

ClipboardThread::run()
at /usr/src/debug/kguiaddons/kguiaddons-6.29.0/
src/systemclipboard/waylandclipboard.cpp:572
QMutexLocker<QRecursiveMutex>::QMutexLocker()
QRecursiveMutex::lock()
QBasicMutex::lockInternal()
QtLinuxFutex::futexWait()

GDB identifies the mutex as:

s_clipboardLock

Therefore, when systemd finally sent SIGABRT, the main thread was waiting for `ClipboardThread`, while `ClipboardThread` was waiting for `s_clipboardLock`. This prevented `plasmashell` from completing its destruction until the 40-second service timeout expired.

The versions involved are:

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

This result appears to supersede my earlier audio/Bluetooth hypothesis. Those events may have changed the shutdown timing, but the process that actually remained stuck was waiting in the KGuiAddons Wayland clipboard teardown. It also does not appear to be a stalled remote filesystem/KIO worker in this captured occurrence.

I have now disabled Plasma's built-in Clipboard/Klipper entry completely:

System Tray configuration
→ Clipboard
→ Never show (disabled)

I will use the system normally and repeat several reboots because the problem is intermittent. This is currently a diagnostic control test, not a confirmed permanent workaround.

I have the complete 309-line, 31 KiB symbolized GDB backtrace. I am not uploading the 504 MiB raw core because it can contain private process memory.

Does this look suitable for an upstream report against `frameworks-kguiaddons`, or is there another package/component that would be more appropriate?

seth · 2026-08-21 14:42:31

Does this look suitable for an upstream report against `frameworks-kguiaddons`

It's not getting better than that and the backtrace will suffice - nobody needs the binary coredump (in this context)

Possibly related: https://bugs.kde.org/show_bug.cgi?id=514512

Arch Linux

#1 2026-08-11 03:13:05

plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#2 2026-08-11 06:47:11

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#3 2026-08-11 16:29:12

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#4 2026-08-11 19:20:13

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#5 2026-08-13 05:54:34

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#6 2026-08-13 05:57:47

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#7 2026-08-13 10:16:47

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#8 2026-08-13 15:48:02

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#9 2026-08-13 16:34:49

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#10 2026-08-17 00:29:26

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#11 2026-08-21 00:17:04

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

#12 2026-08-21 14:42:31

Re: plasma-plasmashell.service stop timeout causes ~40 second reboot delay

Board footer