时间线
- May 27, 2022 一直在正常使用。
- May 28, 2022 早晨重启电脑之后，发现 GNOME 无法进入。遂开始漫长的 debug 之旅。
- May 31, 2022 尝试了新的 debug 思路，遂解决问题。
问题描述
操作
- 启动系统，进入登录界面（gdm）。
- 选择我的常用账户。
- 输入密码，回车。
然后在灰屏界面（tty2）光标卡住。一段时间后，退回到登录界面（tty1）
一些现象
- 不太像是 Nvidia 的问题，因为此问题在 Wayland 和 Xorg 都存在。
- 和用户相关，root 和新建用户都能正常登录。
- 今天才发现这个问题，但是昨天使用电脑的时候没有做什么激进的操作。
- 暂时禁用了所有 GNOME Extensions，问题依然存在。
- 重启已经试过很多次，对这个问题没有影响。
- 和
.zshrc的关系可能不大，因为我chsh到 bash 以后此问题完全相同（.bashrc基本没有改动过，很久很久以前用的了）。
- 通过
top查看比较不同用户的进程，没发现异常。因此不应该是进程冲突的问题。
systemd关键日至如下：May 28 12:45:42 fky-arch systemd[985]: [email protected]: start operation timed out. Terminating. May 28 12:47:12 fky-arch systemd[985]: [email protected]: State 'stop-sigterm' timed out. Killing. May 28 12:47:12 fky-arch systemd[985]: [email protected]: Killing process 1094 (gnome-session-b) with signal SIGKILL. May 28 12:47:12 fky-arch systemd[985]: [email protected]: Killing process 1098 (n/a) with signal SIGKILL. May 28 12:47:12 fky-arch systemd[985]: [email protected]: Main process exited, code=killed, status=9/KILL May 28 12:47:12 fky-arch systemd[985]: Stopped target GNOME Wayland Session. May 28 12:47:12 fky-arch systemd[985]: Stopped target GNOME Shell. May 28 12:47:12 fky-arch systemd[985]: [email protected]: Failed with result 'timeout'.
可以看到在一分半的时间内，没有任何异常日志，而后该 session 直接被杀死。
随后，（在 #archlinux-cn 群友的帮助下）尝试开启了
gnome-session-binary 的 --debug，以及 mutter 的 MUTTER_DEBUG=all 。但是仍然没有有用的信息。转变排查思路
这个问题的关键点在于：“只有常用用户受到了影响”。当时我的想法是：“在家目录下有用户配置导致了这一问题的发生”。
虽然无法通过明确的日志信息来缩小排查范围，但是好在：
- 我们仍然可以通过
tty或者su等方式访问当前用户的文件。
- 其他用户可以正常使用。
因此，我们可以通过二分法来查找（排除）到产生问题的文件。
无法复现问题
然而当我在 28 号当天尝试全量复制
.config 到新建用户目录下之后，新用户依旧能正常登录。为什么不全量复制该用户的所有数据呢？因为我的常用用户下至少有 300G 数据，显然全部复制是没有意义的。
由于看不到转机，我开始尝试卸载、移除一些 GUI 和不常用软件的二进制和配置，但仍然无果。
峰回路转
今天上午我突然开始怀疑是
gsetting 中的某个配置导致了这一问题。因为在全量复制 .config 之后，新用户的壁纸等一系列系统设定并没有同步。虽然在尝试之后我的猜想被否定了，但是这个思路提醒了我：不是所有的配置都在
.config 中。或者换句话说，不光只有用户配置能够影响到系统的行为。而恰巧，我上午在重构 Vim 的配置文件，把
"directory" 从 ~/.vim 迁移到 $XDG_CACHE_HOME/vim/files 中。于是我想到通过修改 XDG 参数，来代替复制文件，来进行粗筛。果然成功了！最终，问题被定位在
.local/share/applications 中。
原因分析
大概在 27 号，我运行过几次
winecfg 。这导致在 .local/share/applications 中有几个软链接指向了家目录和根目录。（并非我直接操作的。）而 GNOME 在初始化过程中搜索 *.desktop 也是会（递归）遍历这个文件夹的。这导致 GNOME 在启动时尝试全局搜索用户文件，进而引发超时，最终被 kill。而这也解释了为什么找不到报错日志——因为没有错误。
其他思考
GNOME 的这种搜索策略是不是有问题，是否应该和
ls -R 一样，将软链接视作文件？