9 个回答
最近配实验室服务器遇到这个问题，顺便记录一下，Ubuntu 20.04 以及 22.04 应该都适用。
- 一般情况下安装
xrdp时会自动安装xorgxrdp包，检查是否已经安装xorgxrdp，如果安装时遇到依赖问题（我的情况是只有从18.04升级上来的那台服务器遇到了这个问题），请顺序执行下面命令以修复依赖
sudo apt install xserver-xorg-core
sudo apt install xserver-xorg-input-all
sudo apt install xorgxrdp- 黑屏的其中一种原因是，桌面环境（例如默认的
ubuntu-desktop或是教程中常用的xfce4）会阻止同一用户第二个会话（session）的启动 ，也就是说 Server 端已经登录的情况下，xrdp 远程桌面就会黑屏。解决方案是在/etc/xrdp/startwm.sh中添加两行内容（通常在test -x /etc/X11/Xsession && exec /etc/X11/Xsession前）
unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR- 黑屏还有一种原因，如果安装了多个桌面环境，那么必须指明会话使用哪一个，否则也会黑屏或闪退。（十有八九是因为已经是桌面版 Ubuntu 但还是按网上的教程安装了
xfce4，然后掉坑里了）。下面示例指明使用 Ubuntu 默认 gnome 桌面环境，使用其他桌面可以相应修改
echo gnome-session > ~/.xsession # for default ubuntu-desktop
# echo xfce4-session > ~/.xsession # for xfce4- 如果有 xrdp 远程桌面与本地桌面体验不一致的问题，可创建
.xsessionrc作为远程桌面的登录脚本，用于在 xrdp 会话（session）建立之前对远程桌面进行设置，
cat <<EOF > ~/.xsessionrc
export GNOME_SHELL_SESSION_MODE=ubuntu
export XDG_CURRENT_DESKTOP=ubuntu:GNOME
export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
EOF- 关于xrdp登录后提示色彩文件授权需要输入密码，可以创建授权文件后重启 polkit 服务
# 编辑授权文件
sudo vim /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla
# 重启 polkit 服务
sudo systemctl restart polkit.service具体文件内容如下
[Allow Colord all Users]
Identity=unix-user:*
Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile
ResultAny=no
ResultInactive=no
ResultActive=yes- 配置完成后记得重启 xrdp 服务
sudo systemctl restart xrdp.service
我的情况，ubuntu20.04,gnome桌面，在windows系统远程ubuntu出现黑屏。解决办法：ubuntu系统下登出用户，远程连接正常。除此之外，若远程登录后不登出直接关闭远程窗口，ubuntu系统登录后无法看到桌面，需要远程后登出才可以使用。
我的方法是安装另外一个桌面，然后在你的主目录下的.xsession文件指定新的桌面。我得20.10用gnome-session不行。
#sudo apt install ubuntu-mate-desktop --install-recommends
#echo mate-session>~/.xsession建议安装推荐包，不然会很丑。
标题：排查一个 xrdp 连接后立即断开问题
原文在本人博客：记录排查 xrdp 连接后立即断开问题
今天在使用 Windows 10 RDP 客户端连接至 ArchLinux 上的 xrdp 服务时，遇到了一个现象：连接可以成功进入登录界面，用户可以选择 xorg 会话类型，并输入用户名和密码。点击登录后，连接立即断开。这表明认证过程可能成功，但会话启动存在问题。需要进行排查。
排查过程如下：
首先，为了获取更多信息，我决定修改 xrdp 的启动脚本以增加日志输出。编辑了 /etc/xrdp/startwm.sh 文件。在该文件中，我增加了日志记录，以便追踪脚本的执行流程。
通过查看日志，我定位到问题发生在脚本的以下部分：
if [ -r ~/.xinitrc ]; then
pre_start
. ~/.xinitrc # 这一行意外退出
post_start
exit 0
fi日志显示脚本在执行 . ~/.xinitrc 这一行后异常退出。这指向用户主目录下的 .xinitrc 文件是问题的根源。
接下来，我编辑了 ~/.xinitrc 文件，试图找出其中的具体问题。我的 .xinitrc 文件中用于启动 Plasma 桌面环境的命令是：
exec /usr/lib/plasma-dbus-run-session-if-needed startplasma-x11根据之前的排查，问题就出在执行这行命令时。为了进一步了解 startplasma-x11 执行时发生了什么，我需要查看它的输出信息。
首先，我确认了 startplasma-x11 是一个可执行的二进制文件，无法直接编辑其源代码（至少在不重新编译的情况下）。
为了捕获 startplasma-x11 的标准输出和标准错误，我修改了 .xinitrc 中的执行命令，将输出重定向到一个日志文件：
exec /usr/lib/plasma-dbus-run-session-if-needed startplasma-x11 2>&1 | tee /var/log/debug/xrdp.log执行上述修改后，再次尝试通过 RDP 连接。连接断开后，我检查了 /var/log/debug/xrdp.log 文件。日志内容显示：
$DISPLAY is not set or cannot connect to the X server.这条错误信息表明 startplasma-x11 认为它无法连接到 X server，或者 $DISPLAY 环境变量未正确设置。然而，xrdp 应该会设置 $DISPLAY 变量。为了确认 $DISPLAY 变量的值，我在执行 startplasma-x11 之前增加了一行 echo 命令到 .xinitrc 中：
echo $DISPLAY
exec /usr/lib/plasma-dbus-run-session-if-needed startplasma-x11 2>&1 | tee /var/log/debug/xrdp.log再次尝试 RDP 连接并检查日志。日志输出了 $DISPLAY 的值：
:10:10 是一个有效的显示编号格式。$DISPLAY 变量显然设置了，但 startplasma-x11 仍报告无法连接 X server。为了理解 startplasma-x11 是如何判断能否连接到 X server 的，我查看了其源代码。通过搜索找到了 KDE Plasma Workspace 的相关仓库以及 startplasma-x11.cpp 文件。
查看源代码片段（ https://github.com/KDE/plasma-workspace/blob/master/startkde/startplasma-x11.cpp ）：
int main(int argc, char **argv)
{
// When the X server dies we get a HUP signal from xinit. We must ignore it
// because we still need to do some cleanup.
signal(SIGHUP, sighupHandler);
qputenv("QT_NO_XDG_DESKTOP_PORTAL", QByteArrayView("1"));
QCoreApplication app(argc, argv);
// Check if a Plasma session already is running and whether it's possible to connect to X
switch (kCheckRunning()) {
case NoX11:
out << "$DISPLAY is not set or cannot connect to the X server.\n";
return 1;
// ...
}
// ...
}
代码显示，startplasma-x11 内部调用了 kCheckRunning() 函数来检查 X server 连接状态。如果 kCheckRunning() 返回 NoX11，则输出错误信息并退出。
接着，我查找了 kCheckRunning() 函数的实现，找到了 startkde/kcheckrunning/kcheckrunning.cpp 文件中的相关代码：
CheckRunningState kCheckRunning()
{
Display *dpy = XOpenDisplay(nullptr);
if (dpy == nullptr)
return NoX11;
Atom atom = XInternAtom(dpy, "_KDE_RUNNING", False);
return XGetSelectionOwner(dpy, atom) != None ? PlasmaRunning : NoPlasmaRunning;
}
kCheckRunning() 函数通过调用 XOpenDisplay(nullptr) 来尝试连接 X server。如果 XOpenDisplay 返回 nullptr，则表示连接失败，函数返回 NoX11。
我查阅了 XOpenDisplay 的手册页（man 3 XOpenDisplay）。手册页中提到：
XOpenDisplay connects your application to the X server through TCP or DECnet communications protocols, or through some local inter-process communication protocol. If the hostname is a host machine name and a single colon (:) separates the hostname and display number... If XOpenDisplay does not succeed, it returns NULL
这就是即使 $DISPLAY 被设置为 :10，XOpenDisplay 仍然可能返回 NULL 的原因。:10 是一个有效的显示编号，但如果 X server 本身没有在该显示上成功启动或监听，XOpenDisplay 将无法连接。
同时，手册页提到了 Xorg 可以接受 -logfile 参数来指定日志文件。这提供了一个新的排查方向：检查 X server（xorgxrdp）本身的日志。
全文搜索 /etc 目录下包含 -logfile 的文件，试图找到 Xorg 的日志配置（此前我还尝试 ps -aux | grep logfile 但是一无所获）。
grep -r "-logfile" /etc结果显示：
/etc/xrdp/sesman.ini:param=-logfile表明 sesman.ini 文件中配置了 -logfile 参数。我查看了 /etc/xrdp/sesman.ini 文件：
[Sessions]
;; X11DisplayOffset - x11 display number offset
; Type: integer
; Default: 10
X11DisplayOffset=10
# ...
param=-logfile
param=.xorgxrdp.%s.log配置中的 X11DisplayOffset=10 与前面 $DISPLAY 的值 :10 相符。param=-logfile 和 param=.xorgxrdp.%s.log 组合起来，意味着 Xorg 的日志文件应该是 .xorgxrdp.10.log（%s 会被替换为显示编号）。
我查看了 .xorgxrdp.10.log 文件（完整路径通常是 /var/log/xrdp/.xorgxrdp.10.log 或者 ~/xorgxrdp.10.log，需要自己用 find 命令定位下）：
[2417333.680] (EE)
Fatal server error:
[2417333.680] (EE) Incompatible xrdp version detected - please recompile(EE)
[2417333.680] (EE)
Please consult the The X.Org Foundation support
at [http://wiki.x.org](http://wiki.x.org)
for help.日志清晰地指出问题所在：Incompatible xrdp version detected - please recompile。即 xrdp 和 xorgxrdp 版本不兼容。
根据错误信息，解决方案是确保 xrdp 和 xorgxrdp 版本兼容，通常通过重新安装或更新它们来解决。在 Archlinux 上，我使用 yay 包管理器执行了更新操作：
yay -S xrdp xorgxrdp更新完成后，需要重启相关的服务使更改生效：
sudo systemctl restart xrdp
sudo systemctl restart xrdp-sesman重启服务后，再次尝试通过 Windows RDP 客户端连接。连接成功，桌面环境正常显示，问题得到解决。
总结一下：先梳理整个启动流程，大致即可，然后一步步定位问题发生点，找到程序对底层服务的调用逻辑，最终通过查看底层服务（Xorgxrdp）的日志，定位到版本不兼容这一根本原因。
亲测有效！！！
问题：有一种情况是长期不操作ubuntu时，系统会自动黑屏。
解决方案：进入ubuntu（图形化），点击：Settings ->Light Locker Settings -> Automatically lock the seeion 更改为 Never。
若设置不成功：打开远程桌面 -> 体验 -> 持久位图缓存 保持勾选状态即可。
如果您在使用 xrdp 远程连接到 Ubuntu 20.04 后遇到黑屏，可能是由于多种原因造成的。 以下是您可以尝试解决问题的一些步骤：
1、检查您的 xrdp 配置：确保您的 xrdp 服务器配置正确以支持您打算使用的桌面环境。 在某些情况下，默认的 xrdp 配置可能与某些桌面环境不兼容。 您可能需要修改 /etc/xrdp 目录中的 startwm.sh 脚本以指定正确的桌面会话。
2、验证会话管理器：确保在 xrdp 配置中设置了正确的会话管理器。 Ubuntu 20.04 的默认会话管理器是 gnome-session。 您可以通过检查前面提到的 startwm.sh 脚本来验证这一点。
3、安装必要的桌面组件：有时，如果缺少所需的桌面组件或软件包，可能会出现黑屏问题。 确保您已经安装了必要的桌面包，例如 ubuntu-desktop 或 xubuntu-desktop，具体取决于您的首选桌面环境。
4、更新 xrdp 和 xorgxrdp：确保安装了最新版本的 xrdp 和 xorgxrdp。 您可以通过运行以下命令使用包管理器更新它们：
sudo apt update
sudo apt upgrade xrdp xorgxrdp5、重新启动 xrdp 服务：进行任何配置更改后，重新启动 xrdp 服务以应用更新。 使用以下命令重新启动服务：
sudo systemctl restart xrdp6、尝试不同的桌面环境：如果问题仍然存在，您可以尝试使用不同的桌面环境，看是否能解决黑屏问题。 例如，您可以安装和使用 xfce4 或 mate-desktop 而不是默认的 GNOME 桌面。
7、检查权限和所有权：验证用户主目录及其内容的权限和所有权设置是否正确。 不正确的权限有时会导致 xrdp 出现问题。
如果上述步骤均无法解决黑屏问题，您可能需要考虑其他远程桌面解决方案或查阅 xrdp 文档或社区以进一步排除故障。
另外，作为专业商业远程控制软件，Splashtop也支持Ubuntu 20.04，连接起来更为简单、稳定，不妨一试。
66666666666666666666
666666
神
神医啊！
有效+1
亲测有效