%20.png)
Приложения snap в Ubuntu при запуске в виртуальных рабочих столах nomachine или x2go выдают ошибку и не запускаются. Это касается только ограниченных snap, а это большинство из них.
Виртуальные рабочие столы nomachine связаны с сервером рабочей станции nomachine или другими продуктами в стиле терминального сервера, а не с базовым клиентом общего доступа к рабочему столу nomachine. Я не использую x2go, но пользователи сообщают о таких же проблемах, поэтому я предполагаю, что это также общий доступ к виртуальному рабочему столу.
Известные обходные пути — либо изменить snap sandboxing, отключив cgroups v2, либо вручную симулировать нормальное значение DBUS_SESSION_BUS_ADDRESS. Первый простой, но драматичный, поскольку cgroups v2 — это большая часть современного опыта Linux, а второе решение — это хак, который может сломаться под несколькими пользователями.
Я не знаю, почему DBUS_SESSION_BUS_ADDRESS неверен, когда nomachine или x2go запускают сеанс. При использовании этих приложений удаленного доступа для доступа к сеансам виртуального рабочего стола нет входа, управляемого традиционным менеджером отображения. Nomachine выполняет вход сам, а затем запускает графический сеанс. Я предполагаю, что x2go делает то же самое. Есть некоторая разница в путях кода, что приводит к неожиданному значению для DBUS_SESSION_BUS_ADDRESS. Я предполагаю, что какая-то часть логики запуска сеанса systemd не вызывается nomachine или x2go. Но мне было трудно это понять. Я понимаю, что у меня нет ни малейшего представления о том, как работает вход в систему Linux, и я не могу найти документацию, которую я мог бы понять.
(Я думаю, что сеанс «совместного использования экрана», подключенный к физически присутствующему сеансу, такому как рабочий стол nomachine, не имеет этой проблемы, поскольку он не обходит менеджер дисплеев)
У меня опыт работы с nomachine, но пользователи x2go сообщают о той же проблеме, и тот же обходной путь работает и там.
При отсутствии виртуального рабочего стола в xubuntu или ubuntu я не могу запустить ограниченные приложения, такие как firefox (если только cgroups v2 не отключены с помощью параметра ядра).
Ошибка при запуске из терминала выглядит так:
tim@ubuntu ~/Desktop $ firefox /user.slice/user-1000.slice/session-c3.scope не является контрольной группой snap
но одной из основных причин проблемы, похоже, является то, что
DBUS_SESSION_BUS_ADDRESS настроен неправильно. У него есть значение, но оно сильно отличается от обычного сеанса display-manager.
При типичном входе в Ubuntu мы видим что-то вроде этого:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
но в сломанном сеансе nomachine мы видим что-то вроде этого:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
Если я вручную устанавливаю DBUS_SESSION_BUS_ADDRESS, то ограниченные снимки работают.
Например, если в nomachine я запускаю xfce следующим образом:
DefaultDesktopCommand "env
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4"
Щелчки работают.
Проблема проявляется только для ограниченных snaps, когда работает cgroups v2. Так что ограниченные snaps, а значит и sandbox, тоже должны быть фактором. По этой причине многие убеждены, что это баг snap, но разработчики snap не очень.
Глядя на странное значение DBUS_SESSION_BUS_ADDRESS, я делаю вывод, что сеанс не устанавливается правильно. Способ, которым nomachine запускает сеанс, должен отличаться от того, как работают менеджеры отображения. DBUS_SESSION_BUS_ADDRESS устанавливается в процессе входа в систему systemd, до начала графического сеанса.
Другая возможность заключается в том, что
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
— это совершенно допустимое значение, но «песочнице» Snap это не нравится (неограниченные приложения Snap не испытывают никаких проблем).
Обходной путь с наименьшими проблемами — отключить cgroups v2, и именно это советует nomachine.
Почему DBUS_SESSION_BUS отличается при входе в систему nomachine или x2go?