关于 GNOME 登录页面灰屏幕卡死的这件事

关于 GNOME 登录页面灰屏幕卡死的这件事

Published
May 31, 2022
Updated
Last updated May 31, 2022
Description
五月28日重启电脑的时候,突然发现 GNOME 无法登入。三天后我终于找到了原因。
Progress
Author
Feng Kaiyu

时间线

  • May 27, 2022 一直在正常使用。
  • May 28, 2022 早晨重启电脑之后,发现 GNOME 无法进入。遂开始漫长的 debug 之旅。
  • May 31, 2022 尝试了新的 debug 思路,遂解决问题。

问题描述

操作

  1. 启动系统,进入登录界面(gdm)。
  1. 选择我的常用账户。
  1. 输入密码,回车。
然后在灰屏界面(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,以及 mutterMUTTER_DEBUG=all 。但是仍然没有有用的信息。

转变排查思路

这个问题的关键点在于:“只有常用用户受到了影响”。当时我的想法是:“在家目录下用户配置导致了这一问题的发生”。
虽然无法通过明确的日志信息来缩小排查范围,但是好在:
  • 我们仍然可以通过 tty 或者 su 等方式访问当前用户的文件。
  • 其他用户可以正常使用。
因此,我们可以通过二分法来查找(排除)到产生问题的文件。

无法复现问题

然而当我在 28 号当天尝试全量复制 .config 到新建用户目录下之后,新用户依旧能正常登录。
为什么不全量复制该用户的所有数据呢?因为我的常用用户下至少有 300G 数据,显然全部复制是没有意义的。
由于看不到转机,我开始尝试卸载、移除一些 GUI 和不常用软件的二进制和配置,但仍然无果。

峰回路转

今天上午我突然开始怀疑是 gsetting 中的某个配置导致了这一问题。因为在全量复制 .config 之后,新用户的壁纸等一系列系统设定并没有同步。
虽然在尝试之后我的猜想被否定了,但是这个思路提醒了我:不是所有的配置都在 .config 中。或者换句话说,不光只有用户配置能够影响到系统的行为
而恰巧,我上午在重构 Vim 的配置文件,把 "directory"~/.vim 迁移到 $XDG_CACHE_HOME/vim/files 中。于是我想到通过修改 XDG 参数,来代替复制文件,来进行粗筛。
果然成功了!最终,问题被定位在 .local/share/applications 中。
notion image

原因分析

大概在 27 号,我运行过几次 winecfg 。这导致在 .local/share/applications 中有几个软链接指向了家目录和根目录。(并非我直接操作的。)而 GNOME 在初始化过程中搜索 *.desktop 也是会(递归)遍历这个文件夹的。
这导致 GNOME 在启动时尝试全局搜索用户文件,进而引发超时,最终被 kill。而这也解释了为什么找不到报错日志——因为没有错误。
notion image

其他思考

GNOME 的这种搜索策略是不是有问题,是否应该和 ls -R 一样,将软链接视作文件?