Ubuntu 24.04 虚拟机开机后 应用首次启动缓慢： Fcitx5 与 GNOME Portal 启动竞态的排查

发布于 14 小时前 1 次阅读

环境：Ubuntu 24.04、GNOME（X11 会话）、虚拟机、Fcitx5 中文输入法
现象：刚登录桌面时打开 Files（Nautilus）等 GNOME 应用要等待很久；过一段时间后恢复正常。
结果：将 Fcitx5 从 im-config 的早期启动方式调整为由 systemd 用户服务在图形会话目标启动时拉起。实测 Files 首次打开很快，中文输入正常。

1. 问题现象

我的 Ubuntu 24.04 虚拟机在开机进入桌面后，第一次点击 Files（Nautilus） 往往很慢。奇怪的是，等一会儿再打开相同应用，速度又恢复正常。

起初怀疑虚拟机性能、磁盘 I/O 或 GNOME 文件索引。但从启动日志看，真正值得关注的是 D-Bus 激活 GNOME Portal 服务时失败并超时。

2. 先检查系统启动耗时

运行：

systemd-analyze blame | head -30
systemd-analyze --user blame | head -30

当时看到的较大耗时包括：

4.180s plymouth-quit-wait.service
2.723s mysql.service
2.225s snap.snapd-desktop-integration.snapd-desktop-integration.service

而 Portal 在 systemd-analyze --user blame 中仅显示：

159ms xdg-desktop-portal.service
112ms xdg-desktop-portal-gnome.service

注意：systemd-analyze blame 展示的不是应用等待 D-Bus 服务激活的完整耗时，不能据此排除超时。故转而查看本次用户会话的日志：

journalctl --user -b --no-pager | grep -Ei 'portal|timeout|failed|nautilus'

其中出现：

Dependency failed for xdg-desktop-portal-gnome.service
Failed to create settings proxy: ... Timeout was reached
xdg-desktop-portal.service: start operation timed out. Terminating.
Failed to start xdg-desktop-portal.service - Portal service.

还出现了 org.gnome.ArchiveManager1 的 D-Bus 激活超时，说明卡顿并非简单的 Nautilus 文件索引耗时。

3. 定位启动顺序问题

查看 GNOME Portal 后端服务的 unit：

systemctl --user cat xdg-desktop-portal-gnome.service

系统中的关键配置如下：

[Unit]
Description=Portal service (GNOME implementation)
After=graphical-session.target
Requisite=graphical-session.target
PartOf=graphical-session.target

[Service]
Type=dbus
BusName=org.freedesktop.impl.portal.desktop.gnome
ExecStart=/usr/libexec/xdg-desktop-portal-gnome

这里要区分两个指令：

  • After=graphical-session.target 规定两者在同一个启动事务中时的排序，并不自动拉起该 target。
  • Requisite=graphical-session.target 要求目标已处于活动状态或正处于启动中，否则本服务的启动请求可能因依赖条件不满足而失败。

第一次启动日志中，GNOME Portal 因依赖失败未能启动，随后发生 D-Bus 超时；数分钟后重新激活时又能成功。这符合图形会话初始化阶段的启动竞态。

为了排除 Snap 桌面集成服务的干扰，先临时屏蔽了：

systemctl --user mask --now snap.snapd-desktop-integration.snapd-desktop-integration.service

重启后 Files 仍然很慢，因此单独禁用该服务不是解决办法。随后对新的开机日志做更精确的筛选：

journalctl --user -b --no-pager -o short-iso \
  | grep -Ei 'graphical-session.target|xdg-desktop-portal|fcitx5|timed out|dependency failed'

关键时间线（当天虚拟机日志使用 PDT，-07:00）：

时间日志事件
01:47:41fcitx5 -d 请求 D-Bus 启动 org.freedesktop.portal.Desktop
01:47:42graphical-session.target 仍为 inactive
01:47:42xdg-desktop-portal-gnome.service 因 dependency 启动失败
01:47:42systemd 才到达 graphical-session.target
01:49:11xdg-desktop-portal.service 启动超时并失败

关键原始日志摘录：

... requested by ... comm="/usr/bin/fcitx5 -d"
... graphical-session.target - Current graphical user session is inactive.
... Dependency failed for xdg-desktop-portal-gnome.service
... Reached target graphical-session.target - Current graphical user session.
... xdg-desktop-portal.service: start operation timed out. Terminating.

这次日志把触发顺序明确串了起来：Fcitx5 在图形会话 target 就绪前请求 Portal；GNOME Portal 后端因依赖不满足拒绝启动；后续 D-Bus 调用出现长时间等待。 至于 Files 内部是否还有其他等待路径，仅凭这些日志无法百分之百证明，但这条链路是最有力的候选原因。

4. 检查 Fcitx5 的启动来源

执行：

im-config -m
cat ~/.xinputrc
systemctl --user list-unit-files | grep -i fcitx
grep -Ril 'fcitx5' /etc/xdg/autostart ~/.config/autostart 2>/dev/null

实际输出中，~/.xinputrc 包含：

# im-config(8) generated ...
run_im fcitx5

同时：

  • 没找到 Fcitx5 的 systemd 用户 unit；
  • 没找到常见目录下的 Fcitx5 XDG 自启动项。

这说明原先由 im-config 配置输入法启动。结合前面的 /usr/bin/fcitx5 -d 日志，可以推断这一路径在 GNOME 图形会话准备完毕前启动了 Fcitx5。

5. 实际采用的修复方案

修复思路：避免由 im-config 过早启动 Fcitx5，改由 systemd 用户服务跟随 graphical-session.target 启动。 这样不需要卸载 Fcitx5 或修改系统自带的 Portal unit。

5.1 备份输入法配置

cp ~/.xinputrc ~/.xinputrc.backup

5.2 创建 systemd 用户服务

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/fcitx5.service

内容：

[Unit]
Description=Fcitx5 Input Method
After=graphical-session.target
PartOf=graphical-session.target
Requisite=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/bin/fcitx5
Restart=on-failure
RestartSec=2

[Install]
WantedBy=graphical-session.target

这里的配置是本次机器上经实际登录测试有效的方案，不应不加检查地套用到所有桌面环境。尤其要注意 WantedBy=、After= 和 Requisite= 的组合行为要以当前发行版、桌面会话与 systemd 日志实际验证；它们并非简单的“延时几秒”命令。

5.3 启用服务并取消早期启动

systemctl --user daemon-reload
systemctl --user enable fcitx5.service
im-config -n none

然后检查 ~/.xinputrc 的内容，再重启：

cat ~/.xinputrc
reboot

输入法注意事项：im-config -n none 会改变输入法启动与环境变量初始化方式。部分应用依赖 GTK_IM_MODULE、QT_IM_MODULE、XMODIFIERS 等变量；不同桌面和应用环境中可能需要额外调整。所以修复后必须测试中文输入，而不能只看服务是否 active。

6. 修复后验证

重启后重新查看日志：

journalctl --user -b --no-pager -o short-iso \
  | grep -Ei 'graphical-session.target|fcitx5|xdg-desktop-portal|dependency failed|timed out'

这一次的关键输出变为：

01:53:22 Reached target graphical-session.target - Current graphical user session.
01:53:22 Started fcitx5.service - Fcitx5 Input Method.
01:53:22 Starting xdg-desktop-portal.service - Portal service...
01:53:23 Started xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).
01:53:23 Started xdg-desktop-portal.service - Portal service.

相比修复前，Portal 相关服务正常启动，本次日志不再出现先前的依赖失败和 90 秒启动超时。

Fcitx5 还打印了几条看上去吓人的信息：

Failed to open wayland connection
Failed to open xim, retrying.

不过本次登录是 X11；随后日志确实出现：

Connecting to X11 display, display name::0.
Loaded addon xim
Created classicui for x11 display::0

因此不能仅凭这些初始化重试信息认定输入法失败。

最重要的是实际体验验证：

  • Files 首次打开明显变快；
  • Fcitx5 中文输入法正常；
  • Portal 不再复现本次观察到的启动超时。

这三点共同支持了启动时序调整确实解决了本机遇到的问题。

7. 回滚与收尾

7.1 若修改后中文输入异常，恢复原配置

systemctl --user disable --now fcitx5.service
rm ~/.config/systemd/user/fcitx5.service
systemctl --user daemon-reload
cp ~/.xinputrc.backup ~/.xinputrc

随后注销重新登录或重启。确认备份文件存在后再执行恢复命令。

7.2 恢复排障时临时屏蔽的 Snap 服务

由于屏蔽 snapd-desktop-integration 并没有改善启动慢的问题，修复后可以恢复它：

systemctl --user unmask snap.snapd-desktop-integration.snapd-desktop-integration.service
systemctl --user is-enabled snap.snapd-desktop-integration.snapd-desktop-integration.service

若原本是 enabled，理论上解除 mask 后应恢复启用状态；可重新登录观察。本次成功的 Files 测试发生在此前屏蔽 Snap 之后，因此恢复 Snap 后再重启复测一次，是完善闭环的推荐步骤。

7.3 保留修复配置备份

mkdir -p ~/ubuntu-fcitx5-backup
cp ~/.config/systemd/user/fcitx5.service ~/ubuntu-fcitx5-backup/
cp ~/.xinputrc ~/ubuntu-fcitx5-backup/

8. 总结与经验

这次故障的典型特征是：开机后的第一次打开应用慢，过一会儿又正常。这并不一定意味着磁盘慢或者虚拟机分配资源不足，也可能是用户会话初始化时的服务依赖竞态。

整个排障过程可以归纳为：

  1. 用 systemd-analyze 做初筛，但不要把它当成全部启动等待时间。
  2. 用 journalctl --user -b 找出 Portal 的真实失败和超时记录。
  3. 查看 xdg-desktop-portal-gnome.service 的 Requisite=graphical-session.target 依赖。
  4. 利用日志时间戳识别最早的 D-Bus 请求者——本例是 Fcitx5。
  5. 排除 Snap 桌面集成组件，再检查 Fcitx5 的启动路径。
  6. 将 Fcitx5 调整为会话就绪后由 systemd 管理，并在重启后同时验证日志、Files 和中文输入。

最终结论：本机上，Fcitx5 早期触发 GNOME Portal 与图形会话尚未就绪形成了启动竞态。调整 Fcitx5 的启动时机后，Portal 正常初始化，Files 首次启动缓慢的问题消失，同时中文输入法仍能正常使用。

本文是一次特定 Ubuntu 24.04 / GNOME X11 虚拟机环境的实测记录，并非所有 Nautilus 启动慢问题的通用根因。若修复后 Portal 正常但 Files 仍慢，应继续排查 Nautilus、GVfs、网络挂载或 I/O，而不是盲目禁用 GNOME 组件。