Ubuntu 26.04 桌面启动卡顿、登录循环完整排查实录

环境：Ubuntu 26.04 GNOME + Wayland，NVIDIA 显卡，双显示器
用户：主账号 oklife，新建辅助账号 yuntian
问题：

• 开机进入桌面后，第一次点击"文件"“回收站"等图标要卡 1 分钟左右；
• 后来甚至演变成登录循环：输入密码后直接回到登录界面，无法进入桌面；
• 同时本机有多个自建 systemd 用户服务（chrome-debug、openclaw-gateway、hermes-gateway、socks2http 等）。

本文记录我从问题发生到恢复的完整过程，并总结出一套实操步骤，帮助你在类似环境中：

• 找出是谁在开机早期拖慢桌面响应；
• 避免用户级 systemd 服务把 GNOME/Wayland 会话拖挂；
• 建立一套"按需启动而非自启"的用户服务使用方式。

一、现象与初始排查：桌面启动卡顿

1. 卡顿症状

每次开机后，进入 GNOME 桌面：

• 点击任何程序图标（包括"文件”、“回收站”）都没有反应；
• 约 1 分钟后，所有之前点击过的窗口集中弹出；
• 之后再点图标就正常了（只卡第一次开机后那段时间）。

这很像某个后台服务在等待超时，前台点击行为被"排队"。

2. 确认资源不是瓶颈

打开终端（Ctrl+Alt+T），执行：

printf '\n===== 时间与会话 =====\n'
date
echo "XDG_CURRENT_DESKTOP=$XDG_CURRENT_DESKTOP"
echo "XDG_SESSION_TYPE=$XDG_SESSION_TYPE"

printf '\n===== 资源 =====\n'
free -h
df -hT
uptime
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -20

我看到的是：

• 内存 61 GiB，可用 47 GiB；
• Swap 未使用；
• / 和 /home 空间充足；
• 系统负载 1.x 左右；
• 没有 CPU/内存打满的进程。

说明这不是纯资源问题。

3. 抓当前启动的错误服务

继续在终端执行：

printf '\n===== 本次启动的错误 =====\n'
journalctl -b -p warning..alert --no-pager | tail -200

printf '\n===== 启动慢服务 =====\n'
systemd-analyze blame | head -40

printf '\n===== Portal 状态 =====\n'
systemctl --user --no-pager --full status \
  xdg-desktop-portal.service \
  xdg-desktop-portal-gnome.service \
  xdg-desktop-portal-gtk.service 2>&1

这里我发现两个关键点：

1. xdg-desktop-portal / portal-gnome 有 120 秒超时：日志中出现 service_start_timeout=120000ms 和 Timeout was reached，与"卡约 2 分钟"高度吻合。
2. 系统有大量自建 user-level 服务：例如 chrome-debug.service、openclaw-gateway.service、hermes-gateway.service、socks2http.service 等，挂在 default.target.wants 里随用户会话自动启动。

这类用户服务在 GNOME 会话启动早期就参与，会和 Wayland/portal 发生时序交互。

二、登录循环：主账号被踢回登录界面

在后来一次重启后，问题升级：

• 在图形登录界面输入 oklife 的密码；
• 屏幕闪一下后又回到登录界面；
• 多次尝试都这样——典型的"登录循环"。

1. 用备用账号确认系统是否还健康

首先要确认是系统炸了还是账号配置炸了。

1.1 进入 TTY

在登录界面按：

• Ctrl + Alt + F3

看到黑底提示输入登录信息。

1.2 创建新账号（例如 yuntian）

用主账号 oklife 登录 TTY 后：

sudo adduser yuntian
sudo usermod -aG sudo yuntian

按提示设置 yuntian 的密码，其他信息可以一路回车跳过。

1.3 用新账号登录桌面

返回图形界面（通常 Ctrl + Alt + F1 或 Alt + F2），使用新账号 yuntian 登录：

• 如果新账号能正常进桌面，说明系统和 GNOME 本身没坏，问题只在 oklife 的用户配置；
• 我就是这种情况。

三、定位问题：用户级 systemd 服务是"炸弹"

回到 yuntian 桌面，打开终端，查看主账号的 user-level systemd 配置：

sudo ls -R /home/oklife/.config/systemd/user

输出类似：

/home/oklife/.config/systemd/user:
chrome-debug.service
hermes-gateway.service
openclaw-gateway.service
socks2http.service
default.target.wants
graphical-session.target.wants
...

/home/oklife/.config/systemd/user/default.target.wants:
chrome-debug.service
hermes-gateway.service
openclaw-gateway.service
snap.prompting-client.daemon.service
snap.snapd-desktop-integration.snapd-desktop-integration.service

/home/oklife/.config/systemd/user/graphical-session.target.wants:
warp-taskbar.service

这说明：

• chrome-debug.service 等在 default.target.wants 中：随用户会话自动启动；

• 其中 chrome-debug.service 的内容是：

  [Unit]
  Description=Chrome Headless Debug
  After=network.target
  
  [Service]
  Type=simple
  ExecStart=/usr/bin/google-chrome --remote-debugging-port=9222 --headless=new --no-sandbox --disable-gpu --disable-dev-shm-usage
  ExecStop=/bin/kill %n
  Restart=on-failure
  RestartSec=5
  
  [Install]
  WantedBy=default.target

  即：开机登录时自动起一个 headless Chrome 做浏览器自动化。

通过 journalctl 我还看到：

• chrome-debug.service 在图形会话刚起来的时候就启动；
• 它通过 D-Bus 触发 portal 服务；
• 在 GNOME Shell/Wayland 尚未完全就绪时就让 portal 承受请求，导致 portal 超时，加重登录问题和启动卡顿。

结论：oklife 账号下的用户级 systemd 服务组合是这次事故的核心因素。

四、修复关键思路：暂时"下线"所有自建用户服务

在确保有新账号可用之后，我决定：

把 oklife 账号的 user-level systemd 单元整体搬走，不再自动启动任何自建服务。
然后测试该账号是否能重新登录，以及启动是否顺畅。

1. 备份并移走 ~/.config/systemd/user

在 yuntian 终端中执行：

sudo mv /home/oklife/.config/systemd/user \
        /home/oklife/.config/systemd/user.broken.$(date +%s)

systemctl --user daemon-reload

这个操作：

• 不删除任何文件，只是把 ~/.config/systemd/user 改名为 user.broken.TIMESTAMP，即完整备份；
• 从此 oklife 的登录流程中，不再存在 user-level 自动服务（chrome-debug、openclaw-gateway、hermes-gateway、socks2http 等）；
• 当前会话的 user systemd（yuntian）重新加载配置，但这对 oklife 无害。

2. 重启并测试 oklife 登录

1. 注销 yuntian → 到登录界面；
2. 整机重启（避免会话残留）；
3. 在登录界面使用 oklife 登录。

结果：

• 登录循环消失，oklife 能正常进入桌面；
• 刚登录时点击"文件"、“回收站"等图标完全没有之前的卡顿，桌面响应恢复正常。

至此，主问题已解决：
登录循环消失 + 启动卡顿消失，说明"oklife 的 user-level systemd 服务组合"确实是根因。

五、如何按需恢复服务（而不是开机自启）

现在的状态：

• oklife 的桌面是"干净"的，不再自动起自建服务；

• 原来的服务文件全部在备份目录中，例如：

  ls /home/oklife/.config/systemd/user.broken.1786520220

  输出：

  default.target.wants
  graphical-session.target.wants
  chrome-debug.service
  hermes-gateway.service
  openclaw-gateway.service
  openclaw-gateway.service.bak.*
  socks2http.service

接下来，我决定：

所有这些服务都不再开机自动起，改为按需手动启动；
并且优先恢复核心网关（openclaw-gateway），暂不自启浏览器自动化（chrome-debug）和旧代理（socks2http）。

1. 恢复一个服务：以 openclaw-gateway 为例

1.1 把服务文件复制回当前用户 unit 目录

在 oklife 桌面终端中：

# 创建当前用户 systemd unit 目录
mkdir -p ~/.config/systemd/user

# 从备份目录复制该服务回来
cp ~/.config/systemd/user.broken.1786520220/openclaw-gateway.service \
   ~/.config/systemd/user/

1.2 重新加载用户单元并启动服务

systemctl --user daemon-reload
systemctl --user start openclaw-gateway.service
systemctl --user status openclaw-gateway.service

• status 中看到 Active: active (running) 即说明服务已正常运行；
• 注意：没有执行 enable，所以它不会挂到 default.target.wants，开机不会自动启用。

1.3 用完后的停用

使用结束后，可以手动停掉：

systemctl --user stop openclaw-gateway.service

其它服务如 hermes-gateway.service 也可以按同样步骤按需启动和停止。

2. 浏览器自动化（chrome-debug）与 socks2http 的建议

• chrome-debug.service（headless Chrome DevTools）易与 GNOME/portal 互动，建议：

  • 不再使用 systemd 自动启动；

  • 改为在需要时直接运行：

    /usr/bin/google-chrome --remote-debugging-port=9222 \
      --headless=new --no-sandbox --disable-gpu --disable-dev-shm-usage

  • 这样 DevTools MCP 仍然可以连接 9222，但不会无声影响登录流程。

• socks2http.service 是旧代理链残留，脚本已缺失，且你不再需要：

  • 保留它在备份目录即可；
  • 不要复制回当前 ~/.config/systemd/user，也不要 start 或 enable。

六、经验总结与建议

1. 用户级 systemd 服务要慎用自启

在 GNOME + Wayland + 多自建服务的环境下：

• ~/.config/systemd/user 里的服务在默认情况下随用户会话自动启动；

• 一旦这些服务在图形会话尚未就绪时触发 portal、D-Bus 或 GPU，会直接影响登录和桌面响应；

• 建议：

  • 只让非常必要、明确测试过的服务自启；
  • 否则全部改为按需启动。

2. 保留备份目录作为"工具箱”

把 old user unit 目录挪到 user.broken.TIMESTAMP 的做法非常有用：

• 既能让登录流程恢复干净；
• 又保留所有服务文件；
• 后面可以按需从备份目录里"抽取"单个服务回来，而不是全盘恢复。

3. 出现登录循环时的操作顺序

推荐顺序：

1. 新建辅助账号，验证系统与桌面是否健康；

2. 在辅助账号下检查主账号的：

   • user systemd services；
   • GNOME 扩展与 dconf；

3. 优先"软禁"整个 ~/.config/systemd/user（挪到备份目录）并重启；

4. 视情况再重置 GNOME 设置、扩展等（本次案例中，仅靠 user-level systemd 的重置就解决了问题）。

附：按需启动服务的简易命令模板

未来你需要时，可以用以下模板：

# 按需恢复某个服务（以 openclaw-gateway 为例）

mkdir -p ~/.config/systemd/user

cp ~/.config/systemd/user.broken.1786520220/openclaw-gateway.service \
   ~/.config/systemd/user/

systemctl --user daemon-reload
systemctl --user start openclaw-gateway.service
systemctl --user status openclaw-gateway.service

# 用完后停掉
systemctl --user stop openclaw-gateway.service

将 openclaw-gateway.service 替换为 hermes-gateway.service 等，就可以按需启动相应服务。

参考来源

• systemd User Services Documentation
• xdg-desktop-portal GitHub
• GNOME Wayland Session Issues