Повторяющаяся ошибка службы TUXEDO Control Center: Не удается получить доступ к /run/user/1000/Xauthority

У меня возникла проблема с сервисом TUXEDO Control Center Service (tccd) на моей системе. Сервис запущен, но он постоянно записывает следующие ошибки каждые 5 секунд о том, что не может получить доступ к /run/user/1000/Xauthority:

Jun 15 10:48:20 m tccd[1971]: ls: не удается получить доступ к '/run/user/1000/Xauthority': Нет такого файла или каталога
Jun 15 10:48:25 m tccd[1971]: ls: не удается получить доступ к '/run/user/1000/Xauthority': Нет такого файла или каталога
Jun 15 10:48:25 m tccd[1971]: Не удалось выполнить onWork() => Ошибка: Команда завершилась неудачей: ls -l /run/user/1000/Xauthority

Я пытался проверить systemctl status tccd, но сервис, похоже, работает нормально:

 tccd.service - TUXEDO Control Center Service
     Loaded: загружен (/etc/systemd/system/tccd.service; включен; заводская предустановка: включена)
     Active: активно (работает) с пятницы, 2024-06-14 13:44:38 CEST; 21 ч. назад
   Main PID: 1971 (tccd)
      Tasks: 6 (лимит: 37541)
     Memory: 103.2M
     CGroup: /system.slice/tccd.service
             └─1971 /opt/tuxedo-control-center/resources/dist/tuxedo-control-center/data/service/tccd --start

Вопрос: Действительно нет файла ‘Xauthority’ в ‘/run/user/1000/’. Почему этот файл может отсутствовать? Следует ли мне воссоздать этот файл? Если он не требуется, есть ли способ настроить tccd, чтобы он перестал искать этот файл, если он не нужен? Может ли эта проблема повлиять на мою систему иными способами?

Любая помощь или предложения будут оценены.

Файл Xauthority содержит “пароль” для графических приложений, чтобы получить доступ к вашему серверу дисплеев X11 (Xorg, Xwayland). Местоположение, по которому ищет ваш сервис, не совсем стандартно, хотя это разумная догадка (на самом деле были попытки сделать этот путь стандартным; я уверен, что видел менеджер дисплеев – возможно, это был LightDM? – который использовал этот путь, и мой собственный ~/bin/startx также использует его).

Если вы используете X11, то стандартное местоположение файла – ~/.Xauthority, но ваш менеджер дисплеев (например, GDM) может выбрать другое местоположение и установить $XAUTHORITY соответственно. Так что, если файл существует:

ls -l ~/.Xauthority
ls -l "$XAUTHORITY"

и содержит разумные данные:

xauth list

то вы можете попробовать создать символьную ссылку на место, где её хочет видеть демон:

ln -s ~/.Xauthority "$XDG_RUNTIME_DIR/Xauthority"

Если вы используете Wayland и ваш композитор (WM) запускает Xwayland, то, скорее всего, он также установит $XAUTHORITY за вас. Чистый Wayland не использует Xauth, но чисто-Wayland рабочие столы редки.

Если вы не используете X11 (ни самостоятельно, ни через Xwayland), то, скорее всего, у вас не будет файла Xauthority, так как нечем управлять доступом. В этом случае – или если вы просто не хотите предоставлять демону доступ к вашему X-дисплею – вы можете вручную создать фиктивный файл Xauthority, используя xauth, как это:

xauth -f <path> add :0 MIT-MAGIC-COOKIE-1 $(mcookie)

где mcookie (или uuidgen|sed s/-//g) генерирует случайный шестнадцатеричный ключ, который затем вставляется в качестве ключа аутентификации для дисплея :0.

Честно говоря, я действительно подозрителен к любым системным демонам, которые пытаются получить доступ к X11. Это может быть оправданным, но это очень плохой дизайн. (Обычно у вас есть отдельный GUI ‘апплет’, который обращается к сервису, вместо этого, например, nm-applet, который связывается с NetworkManager.) Еще более подозрительным является то, что сервис пытается использовать ls -l каким-либо образом – буквально каждый язык программирования (даже shell!) имеет более прямые способы проверить, существует ли файл.