关键词
xrdp 黑屏 部分用户正常
xrdp ubuntu 特定用户黑屏 root正常
gnome-shell Failed to use stored monitor configuration
Invalid mode 3840×2160 for monitor unknown unknown
monitors.xml xrdp 黑屏
xrdp 同服务器不同用户表现不一致
xrdp journalctl 排查 黑屏
xrdp xsession-errors 无报错
gnome-session systemd-service 日志去哪了
xrdp 4K分辨率 黑屏
ubuntu remote desktop black screen specific user only
一、问题现象
环境：Ubuntu（GNOME 桌面）+ xrdp，Windows 客户端通过 mstsc 远程登录。
现象很反常，排查方向一度被带偏：
- 同一台 xrdp 服务器，root 用户在任何一台 Windows 电脑上连接都正常，画面没问题；
- 某个普通用户（本例中是 ikaros），无论换哪台 Windows 电脑连接，始终黑屏；
- 换电脑、换网络、换 RDP 客户端版本都没用——变量完全在 Linux 用户本身，不在客户端。
这一点是定位问题的关键：只要黑屏现象”跟着 Linux 用户走，不跟着客户端电脑走”，就可以直接排除网络问题、客户端 RDP 协议版本问题、显卡驱动在客户端侧的问题，把排查范围收紧到服务器端这个用户自己的会话状态或配置上。
二、问题分析（排查过程）
2.1 先排除”会话冲突 / 残留会话”
最常见的 xrdp 黑屏原因之一是同一用户在服务器端已有一个未正常退出的会话，新连接进来后跟旧会话冲突。用 loginctl list-sessions 检查：
bash
loginctl list-sessions发现该用户对应的 session 确实存在，但深入用 loginctl show-session 查看类型：
bash
loginctl show-session c2 -p Type -p Class -p State -p Service结果：
Service=xrdp-sesman
Type=x11
Class=user
State=activeType=x11 说明 xrdp 拉起的是标准 X11 会话，不是 Wayland，排除了 GNOME 默认 Wayland 会话与 xrdp 不兼容这个最常见的”网络教程”原因。
2.2 确认桌面进程是否真的启动
用 ps -ef | grep 检查该用户名下进程，发现 Xorg、gnome-session-binary、gnome-shell、gnome-shell-calendar-server、dbus-daemon、gnome-keyring-daemon 等一整套 GNOME 组件全部正常启动，CPU 时间也在正常累积，不是僵死进程。
结论：会话本身没有起不来的问题，问题出在”起来了，但没渲染出画面”，方向要转向渲染层。
2.3 .xsession-errors 失去诊断价值
按照网上大多数教程的思路检查 ~/.xsession-errors，结果里只有一堆环境变量设置记录，没有任何报错：
Xsession: X session started for ikaros at ...
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=...
dbus-update-activation-environment: setting DISPLAY=:10.0
...原因：现代 Ubuntu 的 gnome-session 是通过 --systemd-service 方式启动的，gnome-shell、mutter 等真正负责渲染的组件，其日志输出已经被 systemd 接管，不会再写入 .xsession-errors，而是进入了 journalctl。继续在这个文件里找答案是死路，必须换地方查。
2.4 转向 journalctl，找到真正的报错
bash
journalctl _UID=1000 --since "17:00" --no-pager在每一次该用户重连时，都能看到这一行反复出现：
gnome-shell[66909]: Failed to use stored monitor configuration: Invalid mode 3840x2160 (50.000) for monitor 'unknown unknown'这就是真正的元凶。
三、原理分析
GNOME 在用户家目录下维护一份显示器配置缓存文件：
~/.config/monitors.xml这份文件记录了该用户上一次使用某个显示器登录时的分辨率、刷新率、布局信息。每次 GNOME 会话启动（包括 xrdp 拉起的虚拟会话），gnome-shell 都会优先尝试读取并应用这份”上次记住”的配置。
本例中，ikaros 这个用户大概率曾经在某台 4K 分辨率（3840×2160）、刷新率 50Hz 的物理显示器或控制台上登录过一次，GNOME 把这份配置存进了 monitors.xml。
而 xrdp 创建的是一个虚拟显示设备（Xorg 配合 xorgxrdp 模块），它能支持的分辨率/刷新率组合是有限的，尤其 50Hz 这种非标准刷新率，虚拟显卡驱动直接判定为 invalid mode。
于是每次该用户通过 xrdp 重新连接，gnome-shell 启动流程走到”应用上次保存的显示器配置”这一步时就失败，渲染管线卡在一个无效状态——表现出来就是纯黑屏，但底层进程（Xorg、gnome-shell）全部正常存活、没有崩溃、没有报错退出，所以从进程状态上完全看不出异常。
这也解释了现象为什么是”跟用户绑定、跟客户端无关”：
- root 用户没有保存过这种异常的 4K/50Hz 配置（
monitors.xml不存在或配置正常），所以每次都能顺利套用默认值，永远正常； - ikaros 用户只要
monitors.xml里那条坏配置还在，不管换哪台 Windows 电脑、哪个分辨率去连，gnome-shell 启动时第一步要做的事情都是去读这同一份文件，结果必然失败。
四、解决方法
定位到具体文件后，处理非常直接：
bash
# 1. 备份原配置（以防需要回溯）
sudo -u ikaros cp /home/ikaros/.config/monitors.xml /home/ikaros/.config/monitors.xml.bak
# 2. 删除该配置文件，让 gnome-shell 下次启动时按 xrdp 实际汇报的虚拟分辨率重新生成
sudo -u ikaros rm /home/ikaros/.config/monitors.xml
# 3. 杀掉当前残留会话和进程，确保干净重启
sudo loginctl terminate-session c2
sudo pkill -u ikaros -9之后用 Windows 重新连接该用户的 xrdp 会话，gnome-shell 因为没有旧配置可读，会基于 xrdp 当前提供的虚拟显示参数重新生成一份新的、匹配的 monitors.xml，黑屏问题随之消失。
补充思路：如果客户端 RDP 工具支持自定义刷新率（mstsc 本身不支持，只能调分辨率），也可以反向操作——故意把客户端分辨率设成报错中出现的那个值，验证是否复现黑屏，用以交叉确认问题根源，而不直接动手改/删文件。本例中 mstsc 没有刷新率选项，所以最终采用了直接删除文件这个更可靠的方案。
