如何突破Chrome Remote Desktop在Ubuntu上最多32个已加载systemd单元的限制

看起来你碰到了Chrome Remote Desktop（CRD）在Ubuntu环境下的一个隐性限制——默认它只分配32个X display端口（范围通常是:0到:31），这就是为什么加载到第32个用户单元后，再启动新的就会出现Invalid MIT-MAGIC-COOKIE-1 key和无法打开高位display（比如日志里的:25、:50）的错误。下面是几个针对性的解决思路：

1. 扩大Chrome Remote Desktop的display端口范围 #

这是解决问题的核心，因为CRD默认的端口范围直接限制了可同时运行的用户单元数：

• 首先编辑CRD的主配置脚本：

  sudo nano /opt/google/chrome-remote-desktop/chrome-remote-desktop
  

• 在文件里找到定义FIRST_VIRTUAL_DISPLAY和LAST_VIRTUAL_DISPLAY的代码块（通常是Python语法），默认值大概是：

  FIRST_VIRTUAL_DISPLAY = 10
  LAST_VIRTUAL_DISPLAY = 41
  

• 把LAST_VIRTUAL_DISPLAY调整到更高的数值，比如扩大到100，这样就能支持90个左右的用户单元：

  FIRST_VIRTUAL_DISPLAY = 10
  LAST_VIRTUAL_DISPLAY = 100
  

• 保存文件后，重启CRD服务让配置生效：

  sudo systemctl restart chrome-remote-desktop.service
  

2. 排查systemd自身的资源限制 #

虽然核心问题是display端口，但也可以确认下systemd有没有单元数或进程数的限制：

• 检查当前systemd的默认资源限制：

  cat /etc/systemd/system.conf | grep -E '(DefaultLimitNPROC|DefaultLimitNOFILE)'
  

• 如果数值偏低（比如小于65535），可以修改/etc/systemd/system.conf文件，提升限制：

  DefaultLimitNPROC=65535
  DefaultLimitNOFILE=65535
  

• 修改后需要重载systemd并重启系统：

  sudo systemctl daemon-reload
  sudo reboot
  

3. 修复用户X会话的Cookie权限问题 #

日志里的Invalid MIT-MAGIC-COOKIE-1错误，说明新用户的X会话权限没有正确初始化，导致无法访问display端口：

• 针对无法启动的用户，手动初始化其X权限：

  sudo su - <用户名> -c "touch ~/.Xauthority && xauth generate :<对应display编号> . trusted"
  

  你可以结合CRD的端口配置，给每个用户固定一个display编号，避免自动分配时的权限冲突。

4. 优化systemd单元的启动逻辑 #

如果上面的方法还存在偶发问题，可以修改CRD的systemd模板单元，让服务启动时自动处理权限：

• 编辑CRD的systemd模板文件：

  sudo nano /etc/systemd/system/chrome-remote-desktop@.service
  

• 在[Service]区块下添加前置命令，初始化用户的Xauthority：

  [Service]
  ExecStartPre=/bin/su - %i -c "touch ~/.Xauthority && xauth generate :<预设display编号> . trusted"
  ExecStart=/opt/google/chrome-remote-desktop/chrome-remote-desktop --start --new-session
  

  这里的%i会自动替换为服务对应的用户名，你需要把<预设display编号>替换为该用户对应的固定端口，或者结合CRD的自动分配逻辑调整。

总结一下，优先调整CRD的display端口范围，这是解决32个单元限制的关键，再配合权限修复，就能让超过32个用户的CRD服务正常加载运行了。

备注：内容来源于stack exchange，提问作者Rafael