>QDbus will hang for a long time before timing 

It's a bit more complicated. 
Typically if something is not on the bus it will time out instantly.

Unfortunately we mark ksplash as a fake DBus activatable service to avoid races. It starts a small binary that just sits there blocking until the real name comes up and exits (plasma-waitforname) 

It's that combo that breaks things.

In that case a different solution might be more appropriate
One where plasma-waitforname doesn't run for the specific interface when the splash is disabled.

In terms of best long-term solution, I want to drop all of these stages. They're all a mess and rather meaningless. 

There's also the repeated discussion about killing ksplash given how much work we've done on the boot.


In terms of super short fixes; I can apply your patch above, though it's making something that's already a bad hack even longer. Hypothetically does adding an '&' on the end work?

Just adding a '&' to the original line doesn't work because systemd doesn't understand shell commands. Changing the line to ExecStartPost=-/usr/bin/sh "/usr/lib/qt5/bin/qdbus org.kde.KSplash /KSplash org.kde.KSplash.setStage ksmserver &" works fine. You will get some extra error messages in the log though. Since the whole bootup thing might change in the future I would just use the shell encapsulating with a '&' at the end. The plasma-ksplash-ready.service can stay like it was, it doesn't stall the boot, it just creates some error messages.

Regards

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/625

Git commit e7e49916712d2d8efc65d7da1721eb1d31dc65d6 by Henri Chain, on behalf of David Edmundson.
Committed on 17/02/2021 at 09:53.
Pushed by davidedmundson into branch 'master'.

Move ksmserver's ksplash notifying to ksmserver

Previously the call to ksplash was being emitted by plasma-session. This
isn't used in the systemd startup so it was introduced in a somewhat
messy script.

This script has an issue:

If ksplash is disabled the bus name won't be registered. Typically this
isn't an issue. However to avoid a race condition ksplash registers
itself as being DBus activatable, so that the dbus server holds
dispatching the message.

This combo means ksmserver our unit is considered as not running until
our script times out. This then defers other things in the chain that
depend on ksmserver.

Moving the call into the relevant piece of code into ksmserver unifies
things into a single path and gives us more control.

M  +0    -2    ksmserver/plasma-ksmserver.service.in
M  +7    -0    ksmserver/server.cpp
M  +0    -1    startkde/plasma-session/startup.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/e7e49916712d2d8efc65d7da1721eb1d31dc65d6

Git commit a3f5ac1296e93eefaca1f70d48c6c03c688f3946 by David Edmundson.
Committed on 17/02/2021 at 09:58.
Pushed by davidedmundson into branch 'Plasma/5.21'.

Move ksmserver's ksplash notifying to ksmserver

Previously the call to ksplash was being emitted by plasma-session. This
isn't used in the systemd startup so it was introduced in a somewhat
messy script.

This script has an issue:

If ksplash is disabled the bus name won't be registered. Typically this
isn't an issue. However to avoid a race condition ksplash registers
itself as being DBus activatable, so that the dbus server holds
dispatching the message.

This combo means ksmserver our unit is considered as not running until
our script times out. This then defers other things in the chain that
depend on ksmserver.

Moving the call into the relevant piece of code into ksmserver unifies
things into a single path and gives us more control.


(cherry picked from commit e7e49916712d2d8efc65d7da1721eb1d31dc65d6)

M  +0    -2    ksmserver/plasma-ksmserver.service.in
M  +7    -0    ksmserver/server.cpp
M  +0    -1    startkde/plasma-session/startup.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/a3f5ac1296e93eefaca1f70d48c6c03c688f3946