%20.png)
snap apps no Ubuntu quando iniciados em desktops virtuais nomachine ou x2go apresentam um erro e não são executados. Isso se aplica apenas a snaps confinados, que são a maioria deles.
Os desktops virtuais nomachine estão associados ao servidor de estação de trabalho nomachine ou a outros produtos estilo servidor de terminal, e não ao cliente básico de compartilhamento de desktop nomachine. Eu não uso o x2go, mas os usuários relatam problemas idênticos, então acho que ele também compartilha uma área de trabalho virtual.
As soluções conhecidas são alterar o snap sandbox desabilitando o cgroups v2 ou simular manualmente o valor normal de DBUS_SESSION_BUS_ADDRESS. A primeira é simples, mas dramática, já que o cgroups v2 é uma grande parte da experiência moderna do Linux, e a segunda solução é um hack que pode quebrar sob vários usuários.
Não sei porque DBUS_SESSION_BUS_ADDRESS está errado quando nomachine ou x2go inicia a sessão. Ao usar esses aplicativos de acesso remoto para acessar sessões de área de trabalho virtual, não há login gerenciado por um gerenciador de exibição tradicional. O Nomachine faz o login sozinho e depois inicia a sessão gráfica. Presumo que o x2go faça a mesma coisa. Há alguma diferença nos caminhos de código que leva a um valor inesperado para DBUS_SESSION_BUS_ADDRESS. Meu palpite é que alguma parte da lógica de início da sessão do systemd não é invocada pelo nomachine ou x2go. Mas tem sido difícil para mim entender. Sei que não tenho uma ideia básica sobre como funciona o login do Linux e não consigo encontrar documentação que possa entender.
(Acho que uma sessão de "compartilhamento de tela" conectada a uma sessão fisicamente presente, como nomachine desktop, não tem esse problema, pois não ignora o gerenciador de exibição)
Minha experiência é com nomachine, mas os usuários do x2go estão relatando o mesmo problema, e a mesma solução alternativa também funciona lá.
Com um desktop virtual nomachine no xubuntu ou no ubuntu, não consigo iniciar snaps confinados como o firefox (a menos que o cgroups v2 esteja desabilitado por meio de um parâmetro do kernel).
O erro quando iniciado a partir de um terminal é assim:
tim@ubuntu ~/Desktop $ firefox /user.slice/user-1000.slice/session-c3.scope não é um snap cgroup
mas uma das causas principais do problema parece ser que
DBUS_SESSION_BUS_ADDRESS está configurado incorretamente. Ele tem um valor, mas é muito diferente de uma sessão normal do gerenciador de exibição.
Em um login típico do Ubuntu, vemos algo assim:
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
mas na sessão quebrada do nomachine, vemos algo assim:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
Se eu definir manualmente DBUS_SESSION_BUS_ADDRESS, os snaps confinados funcionarão.
Por exemplo, se no nomachine eu iniciar o xfce assim:
DefaultDesktopCommand "env
DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus /usr/bin/startxfce4"
snaps funcionam.
O problema só se manifesta para snaps confinados quando o cgroups v2 está em execução. Portanto, snaps confinados, portanto sandbox, também devem ser um fator. Por esse motivo, muitos estão convencidos de que se trata de um snap bug, mas os snap devs, nem tanto.
Observando o valor estranho de DBUS_SESSION_BUS_ADDRESS, concluo que a sessão não está sendo configurada corretamente. A forma como o nomachine inicia a sessão deve ser diferente da forma como os gerenciadores de exibição funcionam. DBUS_SESSION_BUS_ADDRESS é definido no processo de login do systemd, antes do início da sessão gráfica.
A outra possibilidade é que
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ELpK0GVRdC,guid=877c270e0667562ac373497b63ebf31c
é um valor perfeitamente válido, mas o sandbox do snap não gosta dele (aplicativos snap não confinados não têm problema).
A solução alternativa com menos complicações é desabilitar o cgroups v2 e é isso que o nomachine aconselha.
Por que DBUS_SESSION_BUS é diferente quando nomachine ou x2go fazem o login?