Summary
For single-wayland Treeland sessions, stopping the user compositor does not tear down the user session target graph.
The result is a half-alive session: treeland.service is gone, but dde-session and the rest of the user target stack can remain active.
Why this happens
dde-session starts the session target chain like this:
dde-session.target
dde-session-initialized.target
dde-session-core.target
dde-session-pre.target
Treeland's user compositor unit is installed into dde-session-pre.target.wants/, and it has:
Requisite=dde-session-pre.target
PartOf=dde-session-pre.target
Before=dde-session-pre.target
But dde-session-pre.target itself does not require the compositor unit back.
So the relationship is one-way:
- starting the target starts Treeland
- stopping Treeland does not stop the target chain
treeland.service itself also only unsets environment variables on stop. It does not trigger dde-session-shutdown.target.
Reproduction
I reproduced this with a minimal systemd --user setup that mirrors the shipped target relationships.
With the current relationship:
- Start
dde-session-pre.target
- Start
treeland.service
- Stop
treeland.service
Observed result:
treeland.service stops
dde-session-pre.target stays active
- the session target graph remains alive
That matches the current unit design in-tree.
Why this matters
For single-wayland sessions, the compositor is not just another helper. If it disappears, the session is effectively broken.
Today that means a manual systemctl --user stop treeland.service, a compositor crash, or some restart path can leave a headless session behind instead of producing a clean shutdown transaction.
Proposed direction
Bind dde-session-pre.target back to the compositor unit for Treeland single-wayland sessions.
The simplest systemd-side version I validated is:
[Unit]
Requires=treeland.service
After=treeland.service
on dde-session-pre.target for the Treeland session path.
In the same reproducer, that changes the behavior to:
stop treeland.service also stops dde-session-pre.target
- the half-alive session state disappears
restart treeland.service becomes a coherent transaction again
If making dde-session-pre.target compositor-specific is too broad, an equivalent Treeland-specific session wrapper target would also work.
Related files
In dde-session:
systemd/dde-session-pre.target
systemd/dde-session-core.target
systemd/dde-session-initialized.target
systemd/dde-session-manager.service.in
In treeland:
misc/systemd/dde-session-pre.target.wants/treeland.service.in
misc/systemd/dde-session-shutdown.target.wants/treeland-session-shutdown.service
Summary
For single-wayland Treeland sessions, stopping the user compositor does not tear down the user session target graph.
The result is a half-alive session:
treeland.serviceis gone, butdde-sessionand the rest of the user target stack can remain active.Why this happens
dde-sessionstarts the session target chain like this:dde-session.targetdde-session-initialized.targetdde-session-core.targetdde-session-pre.targetTreeland's user compositor unit is installed into
dde-session-pre.target.wants/, and it has:Requisite=dde-session-pre.targetPartOf=dde-session-pre.targetBefore=dde-session-pre.targetBut
dde-session-pre.targetitself does not require the compositor unit back.So the relationship is one-way:
treeland.serviceitself also only unsets environment variables on stop. It does not triggerdde-session-shutdown.target.Reproduction
I reproduced this with a minimal
systemd --usersetup that mirrors the shipped target relationships.With the current relationship:
dde-session-pre.targettreeland.servicetreeland.serviceObserved result:
treeland.servicestopsdde-session-pre.targetstays activeThat matches the current unit design in-tree.
Why this matters
For single-wayland sessions, the compositor is not just another helper. If it disappears, the session is effectively broken.
Today that means a manual
systemctl --user stop treeland.service, a compositor crash, or some restart path can leave a headless session behind instead of producing a clean shutdown transaction.Proposed direction
Bind
dde-session-pre.targetback to the compositor unit for Treeland single-wayland sessions.The simplest systemd-side version I validated is:
on
dde-session-pre.targetfor the Treeland session path.In the same reproducer, that changes the behavior to:
stop treeland.servicealso stopsdde-session-pre.targetrestart treeland.servicebecomes a coherent transaction againIf making
dde-session-pre.targetcompositor-specific is too broad, an equivalent Treeland-specific session wrapper target would also work.Related files
In
dde-session:systemd/dde-session-pre.targetsystemd/dde-session-core.targetsystemd/dde-session-initialized.targetsystemd/dde-session-manager.service.inIn
treeland:misc/systemd/dde-session-pre.target.wants/treeland.service.inmisc/systemd/dde-session-shutdown.target.wants/treeland-session-shutdown.service