systemctl diz que systemd não é PID 1: e agora?

Executar systemctl start openvpn-client@office e receber uma mensagem de que o sistema não foi iniciado com systemd parece uma falha do serviço. Não é falha do serviço nenhuma: o systemctl que invocou não encontra nenhum gestor em execução com quem falar, por isso nada sobre o OpenVPN foi examinado. sudo não cria um gestor, e instalar um ficheiro unit também não cria. A ordem e a máquina vêm de dois mundos diferentes, e o erro é o único lugar onde isso se tornou visível.

Comece por perguntar que processo detém o PID 1 onde a ordem é executada, porque essa resposta decide se as units existem sequer.

O erro nomeia o ambiente, não o OpenVPN

systemctl é um cliente, não um gestor. Liga-se ao gestor do sistema através de um socket e, quando não há nenhum gestor do outro lado, imprime a mensagem que as pessoas colam nos fóruns. ps -p 1 -o pid=,comm= mostra o que corre realmente como PID 1, e a resposta é muitas vezes uma shell, um invólucro init ou o ponto de entrada do próprio contentor. Nessa situação, um ficheiro unit pode ser perfeitamente válido e mesmo assim nunca ser lido. Repetir a ordem como root só altera as credenciais do cliente.

Leia a mensagem completa antes da primeira linha. Um erro do próprio gestor, como uma unit em falta ou uma condição falhada, significa que chegou a um; este erro significa que não.

WSL: ativar o systemd é uma alteração de configuração

O WSL ganhou suporte para o systemd em versões posteriores, mas a funcionalidade é ativada por distribuição e apenas onde a versão instalada do WSL a suporta. wsl --version no lado do Windows mostra o que tem, e o /etc/wsl.conf da distribuição contém [boot] uma secção com systemd=true. Edite esse ficheiro sem remover as secções que já existem e depois reinicie a instância WSL para que a alteração produza efeito. wsl --shutdown para todas as distribuições em execução, por isso guarde o trabalho primeiro.

Depois de reabrir, confirme o gestor antes de mexer na unit do OpenVPN: ps -p 1 -o comm= deveria mostrar systemd. Ativar o systemd não fornece perfil, credencial nem nome de instância, por isso o próximo erro dirá respeito a um desses aspetos e não ao PID 1.

Os contentores executam o seu ponto de entrada, não units

Um contentor normal arranca o que o seu ponto de entrada ou a sua ordem especifica, e não é uma máquina arrancada com systemd, instale os pacotes que instalar. Acrescentar systemctl à imagem dá-lhe um cliente sem nada a que se ligar. No Community OpenVPN, o padrão suportado costuma ser um processo em primeiro plano, openvpn --config /path/to/client.conf, iniciado pelo ponto de entrada e supervisionado de fora. Esse proprietário trata do arranque, dos sinais e do encerramento, e deveria ser a única coisa a gerir o túnel.

Nunca lance uma cópia interativa ao lado de um ponto de entrada que já gere esse túnel, porque dois processos vão lutar pelo dispositivo e pelas rotas. Um processo init mínimo dentro do contentor recolhe os filhos e reencaminha sinais; não transforma a imagem num anfitrião com units.

Se uma implementação precisar mesmo de systemd dentro de um contentor, precisa de uma imagem concebida de propósito para isso, não de privilégios adicionais acrescentados até que systemctl deixe de se queixar.

Leia o erro seguinte quando o gestor existir

Assim que um gestor real arranca o serviço, começam os erros úteis. Uma falha de permissão de dispositivo, um erro de análise da configuração, uma credencial em falta e um par inalcançável são quatro problemas diferentes que a mensagem sobre PID 1 nunca testou. Leia-os pela ordem em que a unit os produziu, usando journalctl -u openvpn-client@office -n 50 num anfitrião com systemd, ou executando o cliente em primeiro plano onde não existe nenhum gestor. A execução em primeiro plano é também a forma mais rápida de confirmar que o próprio perfil funciona.

Mantenha os dois ambientes separados nas suas notas: o anfitrião que executa o túnel e o local onde escreve as ordens.