梦行志
所有文章 梦 行 志 标签 分类 关于 游乐帮
梦行志

目录

Ubuntu 桌面启动卡顿与 xdg-desktop-portal 超时：完整排查实录

从 1 分钟卡顿到彻底修复，用 journalctl 定位 portal 超时根因

梦行志 收录于 码艺轩・以技立身，实干谋生
   约 1851 字   预计阅读 4 分钟 
/images/Code-Art-Studio-images/ubuntu-desktop-lag-portal-timeout-troubleshooting/ubuntu-desktop-lag-portal-timeout-troubleshooting.webp

Ubuntu 桌面启动卡顿与 xdg-desktop-portal 超时：完整排查实录

环境：Ubuntu 26.04 GNOME + Wayland，NVIDIA 显卡，双显示器
用户：主账号 oklife
问题：开机进入桌面后，第一次点击"文件"“回收站"等图标要卡 1 分钟左右，之后才集中弹出窗口。

这一篇只聚焦启动卡顿，以及如何用 journalctl、systemd-analyze 和 portal 状态定位问题根源。

一、问题现象：只在"刚登录后"卡

具体表现：

  • 开机 → 输入密码 → 进入 GNOME 桌面；

  • 点击"文件”、“回收站”、VS Code 等图标：

    • 窗口不弹，有时候连鼠标等待指针都没有；

  • 等大约 1 分钟后，所有之前点击过的窗口一次性弹出；

  • 从此之后，再点图标就秒开，整个一天都正常。

显然，这不是单个应用的问题，而是桌面会话在刚启动时被某个后台服务阻塞。

启动卡顿时间线图

二、先排除资源瓶颈（内存/磁盘/CPU）

打开终端（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

重点看：

  • free -h：内存和 Swap 是否充足；
  • df -hT：/、/home 是否有足够空间；
  • uptime：load average 是否异常高；
  • ps：是否有某个进程在开机时吃满 CPU。

我的输出大致是：

  • 内存：61 GiB，可用 47 GiB；
  • Swap：0 使用；
  • 根分区和 home 分区空间都在 40%–80%；
  • 系统负载 1.x 左右；
  • 没有明显的 100% CPU 进程。

这一步确认：卡顿不是因为内存/磁盘/CPU被打满。

三、用 journalctl 查看本次启动中的错误

接下来利用 journalctl 查看当前这次启动的警告与错误：

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

你会看到很多系统服务信息，关键是找出跟桌面/portal/D-Bus 相关的几行。例如：

… Failed to activate service 'org.freedesktop.portal.Desktop': timed out (service_start_timeout=120000ms)
… Failed to activate service 'org.freedesktop.impl.portal.desktop.gnome': timed out (service_start_timeout=120000ms)

这里两点非常关键：

  • service_start_timeout=120000ms → 120 秒，也就是 2 分钟；
  • 这和你"第一次点击卡 1–2 分钟"的体感高度一致。

结论：xdg-desktop-portal / portal-gnome 在本次启动中发生了 120 秒超时，是卡顿的直接信号。

journalctl超时日志

四、查看哪些服务启动慢（systemd-analyze blame）

用 systemd-analyze 看哪些服务启动耗时较长：

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

你会看到类似这样的输出：

1h 56min 20.864s snapd.service
6.057s apt-daily-upgrade.service
5.889s NetworkManager-wait-online.service
...

虽然 snapd.service 看起来很夸张，但它通常不是桌面点击卡顿的唯一原因。真正关键的是：

  • portal 的 120 秒超时；
  • 以及是谁在 图形会话尚未完全就绪 的时候提前触发了 portal。

五、检查 portal 服务当前状态

看当前 portal 服务的状态：

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

正常情况下，你会看到类似：

● xdg-desktop-portal.service - Portal service
     Loaded: loaded ...
     Active: active (running) since ...
...
● xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)
     Active: active (running) since ...
...
● xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)
     Active: active (running) since ...

但你要用 journalctl 去看它们启动时是否有报错。

六、找出是谁提前触发了 portal（Chrome 自动化的线索）

我用下面的命令抓了本次启动的关键日志片段：

journalctl -b --since '2026-08-12 13:05:00' --until '2026-08-12 13:08:30' \
  -o short-precise --no-pager | \
grep -Ei 'chrome|xdg-desktop-portal|cannot open display|timeout|timed out|graphical-session|gnome-shell|Xwayland|dbus'

在这个时间窗口里，看到了非常关键的顺序：

13:05:21.603891 systemd[2348]: Started chrome-debug.service - Chrome Headless Debug.
...
13:05:21.885923 google-chrome[2557]: DevTools listening on ws://127.0.0.1:9222/devtools/browser/...
...
13:05:21.964150 dbus-daemon[2537]: Activating via systemd: service name='org.freedesktop.portal.Documents' unit='xdg-document-portal.service' ...
...
13:05:21.982266 gnome-shell[2864]: Running GNOME Shell (using mutter 50.1) as a Wayland display server
...
13:06:00–13:06:37 portal: Timeout / service_start_timeout=120000ms

时间线归纳：

  1. 用户会话刚起来，chrome-debug.service 自动启动（headless Chrome，监听 9222）。
  2. 这个 headless Chrome 通过 D-Bus 激活 portal (xdg-document-portal, xdg-desktop-portal 等)。
  3. 此时 GNOME Shell / Wayland / Xwayland 尚未完全就绪，portal 部分调用 cannot open display。
  4. 之后载入 GNOME Shell，portal 进入超时等待，前台点击操作被卡住，等 120 秒超时后才恢复。

这说明：桌面启动卡顿与 xdg-desktop-portal 超时，和用户级自动启动的 headless Chrome 强相关。

systemd启动时序图

七、启动卡顿的修复思路

针对这类问题，核心策略是：

  1. 确认 portal 超时存在 → 用 journalctl。

  2. 找出哪个程序在 GNOME/Wayland 尚未就绪时提前触发了 portal → 通过关键时间片的日志。

  3. 对该程序的启动模式进行调整：

    • 改为手动启动，而不是开机自动起；
    • 或延迟到图形会话就绪之后再启动。

在我的案例里，最终采用的是：

  • 把 oklife 的整个 ~/.config/systemd/user 挪到备份目录，暂时不自动启动任何用户级服务；
  • 在此基础上，把网关服务（openclaw-gateway、hermes-gateway）改为按需手动启动；
  • 浏览器自动化（headless Chrome）改用脚本形式手动运行，而不是 systemd 默认自启。

这样，桌面启动卡顿彻底消失，portal 超时不再出现。

修复前后对比

关键命令速查

目的命令
查看本次启动的错误journalctl -b -p warning..alert --no-pager
查看启动慢的服务systemd-analyze blame | head -40
检查 portal 服务状态systemctl --user status xdg-desktop-portal*.service
抓取关键时间片日志journalctl -b --since '...' --until '...' | grep -Ei 'portal|chrome|dbus'
查看 D-Bus 激活记录journalctl --user -u dbus-daemon -o json

参考来源

关联阅读

  • [[Ubuntu 26.04 桌面启动卡顿、登录循环完整排查实录]]
  • [[Ubuntu 26.04 开启 WARP 后 apt update 失败：最省命的排查与修复]]
更新于 2026-08-12
 Ubuntu, GNOME, Wayland, Systemd, Portal, 排障, Desktop
返回 | 主页