Description
dms.service is Type=dbus with BusName=org.freedesktop.Notifications, so systemd keeps the start transaction open until the shell claims that name — which happens only once the whole QML tree is loaded. The unit sets TimeoutStopSec=10 but leaves the start timeout to whatever the distribution defaults to.
On CachyOS that default is 15 s:
$ systemctl --user show dms.service -p TimeoutStartUSec --value
15s
$ grep -r DefaultTimeoutStartSec /usr/lib/systemd/user.conf.d/
/usr/lib/systemd/user.conf.d/00-timeout.conf:DefaultTimeoutStartSec=15s
$ pacman -Qo /usr/lib/systemd/user.conf.d/00-timeout.conf
owned by cachyos-settings 1:1.4.0-1
A start that succeeds here takes 7 s, so there are eight seconds of margin. Under load that margin goes, systemd kills the shell mid-startup, and Restart=on-failure brings it straight back into the same race. From one journal:
16:00:14 Scheduled restart job, restart counter is at 1.
16:00:29 dms.service: start operation timed out. Terminating.
16:00:31 Scheduled restart job, restart counter is at 2.
16:00:46 dms.service: start operation timed out. Terminating.
16:00:48 Scheduled restart job, restart counter is at 3.
...
16:01:49 Started Dank Material Shell (DMS).
Six consecutive kills at exactly fifteen seconds, then four more half an hour later. Every one of them status=143.
Why it is worth fixing upstream
The restarts are mostly invisible — the shell comes back and the session looks fine — but they are not free. Anything the shell holds only in memory is dropped each time; that is how I found this, chasing an idle inhibitor that kept switching itself off (#3123).
Any distribution is free to lower DefaultTimeoutStartSec for boot speed, and that choice is reasonable for a small daemon. A graphical shell that does colour extraction from the wallpaper before it can claim its bus name is not a small daemon, and it is the only party that knows how long it needs.
Suggested fix
Declare the start budget in assets/systemd/dms.service, next to the stop budget that is already declared:
90 s is systemd's own default — the value CachyOS lowered globally — so on distributions that do not touch it nothing changes at all.
Workaround
A user drop-in, for anyone hitting this before the unit ships one:
# ~/.config/systemd/user/dms.service.d/10-start-timeout.conf
[Service]
TimeoutStartSec=90s
Verified: TimeoutStartUSec goes 15s → 1min 30s after systemctl --user daemon-reload, with no restart of the running shell needed.
Environment
- CachyOS (rolling), Wayland/niri
- dms v1.5.3, Quickshell 0.3.0, distro packaging (
dms-shell 1.5.3-1)
Description
dms.serviceisType=dbuswithBusName=org.freedesktop.Notifications, so systemd keeps the start transaction open until the shell claims that name — which happens only once the whole QML tree is loaded. The unit setsTimeoutStopSec=10but leaves the start timeout to whatever the distribution defaults to.On CachyOS that default is 15 s:
A start that succeeds here takes 7 s, so there are eight seconds of margin. Under load that margin goes, systemd kills the shell mid-startup, and
Restart=on-failurebrings it straight back into the same race. From one journal:Six consecutive kills at exactly fifteen seconds, then four more half an hour later. Every one of them
status=143.Why it is worth fixing upstream
The restarts are mostly invisible — the shell comes back and the session looks fine — but they are not free. Anything the shell holds only in memory is dropped each time; that is how I found this, chasing an idle inhibitor that kept switching itself off (#3123).
Any distribution is free to lower
DefaultTimeoutStartSecfor boot speed, and that choice is reasonable for a small daemon. A graphical shell that does colour extraction from the wallpaper before it can claim its bus name is not a small daemon, and it is the only party that knows how long it needs.Suggested fix
Declare the start budget in
assets/systemd/dms.service, next to the stop budget that is already declared:TimeoutStartSec=90s90 s is systemd's own default — the value CachyOS lowered globally — so on distributions that do not touch it nothing changes at all.
Workaround
A user drop-in, for anyone hitting this before the unit ships one:
Verified:
TimeoutStartUSecgoes15s→1min 30saftersystemctl --user daemon-reload, with no restart of the running shell needed.Environment
dms-shell 1.5.3-1)