systemctl - usuário não disponível para o usuário de dados www

Question

systemctl --user parece estar funcionando bem para o usuário da área de trabalho:

dev@dev-VirtualBox:~$ systemctl --user > /dev/null
dev@dev-VirtualBox:~$ echo $?
0

Mas ao executar o mesmo comando sob o usuário www-data, recebo uma resposta inesperada

dev@dev-VirtualBox:~$ sudo su www-data -s /bin/bash
www-data@dev-VirtualBox:~$ systemctl --user > /dev/null 
Failed to connect to bus: No such file or directory 
www-data@dev-VirtualBox:~$ echo $? 
1

Como ativar systemctl --user aqui?

Executando o Ubuntu 16.04

    

Answer 1

Então eu consegui descobrir a peça que faltava no quebra-cabeça, finalmente. Graças a algumas excelentes dicas do @JdeBP, consegui determinar:

• systemd - o usuário estava executando o www-data
• DBUS_SESSION_BUS_ADRESS parece ser ignorado no Ubuntu
• XDG_RUNTIME_DIR NÃO foi definido

A configuração de XDG_RUNTIME_DIR para exportar "/ run / user / $ UID" resolveu meu problema

Etapas que segui para obter o comportamento pretendido:

% sudo loginctl enable-linger www-data # Enable systemd --user service to start at boot
% XDG_RUNTIME_DIR="/run/user/$UID" systemctl --user # Access services as www-data without actually logging in

    

Answer 2

A instância por usuário do systemd é iniciada por um gancho no processo de login, um pam_systemd PAM, tanto para o login do terminal virtual / real comum quanto para o login remoto via SSH e de outra forma. / p>

Você não está efetuando login. Você está aumentando os privilégios de sua sessão de login existente com sudo su www-data . (A propósito, isso é redundante. sudo -u www-data irá diretamente para www-data sem seus comandos em execução como o superusuário.) Você não chamou o gancho.

Portanto, a instância de systemd por usuário do www-data não foi iniciada e systemctl --user não encontra nada com o que conversar.

Você pode iniciá-lo manualmente:

% sudo install -d -o www-data /run/user/'id -u www-data'
% sudo systemctl start user@'id -u www-data'

(Se você fez isso na ordem errada, então pare o serviço e faça-o na ordem correta. Fazê-lo na ordem errada acaba em um estado onde o diretório de tempo de execução está vazio e não tem o D-Bus e outros arquivos de soquete, mas o serviço está em execução e nunca se comunicará com os clientes.)

O problema é que sua variável DBUS_SESSION_BUS_ADDRESS precisa ser alterada para que os programas cliente do Desktop Bus como systemctl falem com o broker Desktop Bus da outra conta quando você os executar com os privilégios dessa outra conta:

% sudo -u www-data DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/'id -u www-data'/bus systemctl --user

Este é o caminho mais simples. A maneira mais complexa é ajustar a configuração do PAM para que sudo chame o gancho pam_systemd . No entanto, isso tem efeitos colaterais, especialmente com relação à variável de ambiente XDG_RUNTIME_DIR , que você provavelmente não deseja. Apenas tente esta alternativa se tiver certeza de que está tudo bem com os efeitos da introdução de pam_systemd em sudo .

Leitura adicional

• Jonathan de Boyne Pollard (2014). Não abuse do su para eliminar privilégios de usuário . Respostas frequentemente dadas.
• Lennart Poettering e cols. (2017). pam_systemd . páginas de manual do systemd . Freedesktop.org.