登录之后，谁来接管桌面？

换成终端风格的登录界面，要不要把桌面启动方式一起换掉？桌面能打开，为什么自启动和注销又不正常？这两类问题经常被混在一起，因为从输入密码到进入桌面，看起来只是一次动作，实际却经过了几次职责交接。

先拆开登录服务和登录界面#

在 greetd 的组合里，greetd 是后台登录服务，greeter 是用户看见并操作的界面。greetd 按配置启动 greeter；greeter 收集用户名，并与服务交换认证提示、用户回答和结果。界面负责呈现交互，服务端负责推进认证与会话流程。

因此，“greeter 认证通过后把命令发过去”只是口语化描述。更准确的过程是：greeter 请求创建会话，greetd 发回需要回答的认证消息，greeter 把回答交回，直到认证成功；然后才请求启动所选命令。提示不一定只有一轮密码输入，界面不能假设认证永远只有一次问答。[1]

IPC 的 start_session 请求携带命令参数数组 cmd 与环境数组 env，并不是“命令名、独立 args 字段、环境”三件任意拼接的数据。配置 greeter 时通常不必自己构造协议，但理解这层边界有助于分清：身份是否验证成功，与最终是否启动了正确命令，是两个检查点。

换界面，究竟换了哪一层#

greetd 的 default_session 指默认启动的会话，通常就是登录界面。这里的 user 是运行 greeter 的账户，不是你随后在界面里选择登录的账户。把两个身份混在一起，会误读配置的作用。

下面是结构示例：假设 tuigreet 和 sway 已安装、运行 greeter 的账户及服务由系统正确配置。它展示参数之间的关系，不是一份可以覆盖任意发行版现有配置的安装脚本。NixOS 等管理这些文件的系统，应使用对应模块表达配置。[2]

[default_session]
command = "tuigreet --cmd sway"
user = "greeter"

这里 greetd 启动的是 tuigreet；--cmd sway 是 tuigreet 提供的默认会话命令。前者决定登录界面怎么出现，后者决定登录之后启动什么。

tuigreet 还可以读取会话目录中的 Desktop Entry，提供会话选择。它支持记住用户名、记住会话等不同选项；例如 --remember 与 --remember-session 不是同一件事。扫描目录、缓存权限和命令覆盖关系仍要按当前版本配置，不能仅凭“基于 greetd”就推断其他 greeter 也有同样行为。[3]

选型时先区分两个动作：保留 greetd 而更换 greeter，是更换登录交互实现；改用自行组织登录流程的另一套登录管理器，则连后台登录服务也换了。后者还要重新核对服务、认证配置、会话发现和恢复入口，不能当作只换一个皮肤。

uwsm 接手的是图形会话#

登录成功之后，compositor 负责窗口与显示，但图形会话还包含其他工作：准备环境，把程序放进合适的 systemd 用户单元，组织自启动，以及退出时按依赖关系清理。uwsm 面向独立的 Wayland compositor，把这些工作接到 systemd 的用户管理器上；它不提供密码登录界面。

这里至少有三个容易混淆的对象：systemd-logind 记录的登录会话、systemd 用户管理器中的单元，以及 compositor 显示出来的桌面。它们有联系，但不是三个名字指同一件事。一个登录会话可以启动图形会话，而用户管理器中的某些服务也可能早于桌面存在。

uwsm 组织 compositor 单元、环境准备与就绪过程，并与图形会话相关 target 衔接。应用若经 uwsm app 启动，会得到相应的 systemd 管理方式；这里的进程与资源管理，不应被误读成对不可信程序的安全隔离。[4]

对于本来就有完整会话管理器的桌面环境，不要先假定还需要再包一层 uwsm。应先遵循该桌面的启动方式，再判断是否有受支持的集成路径。选择 uwsm 的理由，应当是补足当前 compositor 组合的会话管理，而不是因为它与 greeter 出现在同一篇配置教程里。

真正的衔接点是启动命令#

登录界面列出的会话名称，并不能证明它启动的是哪一层。关键是所选条目的 Exec 最终执行什么。uwsm 官方文档给出了通过 Desktop Entry 接入显示管理器的方式；下面用通用名称保留这个结构：

[Desktop Entry]
Name=Example compositor (UWSM)
Type=Application
TryExec=uwsm
Exec=uwsm start -- example-compositor.desktop
DesktopNames=example;

这里假设另有一个真正启动 compositor 的 example-compositor.desktop。外层条目应使用不同文件名，不能指向自己，也不能再引用一个已经包了 uwsm 的条目，否则会把启动层重复包进去。示例中的 compositor 名称需替换为实际安装且受支持的入口。[4]

条目放在哪里还取决于登录端如何发现会话。常见路径位于数据目录下的 wayland-sessions，但具体 greeter 可以配置自己的扫描目录。即使文件已经存在，新登录界面没有扫描到那个目录，也不会凭空列出它。

所以，“换 greeter 与选 uwsm 可以分别决定”是一种架构上的分工，并不意味着任意组合都自动兼容。替换登录界面后，至少重新核对条目能否被发现、命令参数是否被正确传递，以及所需环境是否可用。

桌面已出现，环境仍可能没交接完#

在终端里执行 export 会影响该进程后续启动的子进程；这并不自动修改一个早已运行的 systemd 用户管理器的激活环境。于是，同一个应用从终端打开正常，从服务或自动启动入口打开却失败，是值得沿环境传递链检查的线索。

Wayland compositor 启动后才能确定的一些变量，需要交给后续应用使用。uwsm 文档特别讨论了 WAYLAND_DISPLAY、可能存在的 DISPLAY 和就绪通知；某些 compositor 已完成所需集成，另一些需要在其启动流程的合适位置执行 uwsm finalize。不要在不了解现有集成的情况下重复导入整份环境。[4]

从 kmscon 启动图形会话时，还多了一层终端与图形会话的交接。那属于控制台与图形程序之间的终端、显示资源交接，不能只靠更换 greeter 解释。排查黑屏时，应先确认登录端、启动端和图形端的实际组合，再查对应日志；“黑屏一定是 DRM master 未释放”这样的单一根因判断并不成立。

自启动不是一个 target 的魔法#

graphical-session.target 用来表达图形会话的生命周期关系，但它的 active 状态不能独自证明所有应用已就绪。XDG 自启动还涉及条目生成、依赖拉起、环境准备和条目条件。

在 systemd 这条路径上，systemd-xdg-autostart-generator 将符合条件的 Desktop Entry 转换为用户服务，再由桌面会话接入 xdg-desktop-autostart.target。条目中的 Hidden、OnlyShowIn、NotShowIn 或 TryExec 等条件都可能影响是否启动。[5]

这也是为什么“输入法没自启动，所以肯定没走 uwsm”过于武断。条目可能没生成，生成后可能没有被拉起，也可能已经启动却因环境或程序错误退出。应先确定失败发生在哪一步，再决定修改谁。

沿着交接点读配置与日志#

下面是一组观察用命令，需要相应工具和读取日志的权限。单元名称可能随安装组合不同而变化；先列出实际名称，再针对目标看日志。不要把示例中的名字直接当作本机一定存在的服务。

systemctl status greetd.service
journalctl -b -u greetd.service --no-pager

systemctl --user status graphical-session.target
systemctl --user status xdg-desktop-autostart.target
systemctl --user list-units --all 'wayland-*' 'app-*@autostart.service'
systemctl --user --failed

# 在列出的实际服务名上继续检查
journalctl --user -b -u example.service --no-pager

若需要退出由 uwsm 管理的会话，应按其退出机制处理；uwsm stop 会结束图形会话相关单元，可能使绑定的登录会话一并结束，执行前要保存工作。它不是只读排查命令，也不应被放进自动尝试的修复循环。[4]

把这条链读清楚之后，选择就具体了：想换登录外观，调整登录交互；想改变会话启动，检查 Desktop Entry 和启动命令；想解决自启动或退出清理，检查会话依赖与环境。每次改动都能对应到一个明确的交接点。