Executar systemctl start openvpn-client@office e recibir unha mensaxe de que o sistema non se iniciou con systemd parece un fallo do servizo. Non é ningún fallo do servizo: o systemctl que invocaches non atopa ningún xestor en execución co que falar, así que non se examinou nada relacionado con OpenVPN. sudo non crea un xestor, e tampouco o crea instalar un ficheiro de unidade. A orde e a máquina veñen de dous mundos distintos, e o erro é o único lugar onde iso se fixo visible.

Comeza preguntando que proceso posúe o PID 1 alí onde se executa a orde, porque esa resposta decide se as unidades existen sequera.

O erro nomea o contorno, non OpenVPN

systemctl é un cliente, non un xestor. Conéctase ao xestor do sistema mediante un socket e, cando non hai ningún xestor ao outro lado, imprime a mensaxe que a xente pega nos foros. ps -p 1 -o pid=,comm= mostra que se executa realmente como PID 1, e a resposta adoita ser un shell, un envoltorio init ou o punto de entrada propio do contedor. Nesa situación, un ficheiro de unidade pode ser perfectamente válido e aínda así non lerse nunca. Repetir a orde como root só cambia as credenciais do cliente.

Le a mensaxe completa antes da primeira liña. Un erro do propio xestor, como unha unidade ausente ou unha condición fallida, significa que chegaches a un; este erro significa que non.

WSL: activar systemd é un cambio de configuración

WSL obtivo soporte para systemd en versións posteriores, pero a función actívase por distribución e só onde a versión instalada de WSL a admite. wsl --version no lado de Windows indica que tes, e o /etc/wsl.conf da distribución contén [boot] unha sección con systemd=true. Edita ese ficheiro sen eliminar as seccións que xa están, e despois reinicia a instancia de WSL para que o cambio surta efecto. wsl --shutdown detén todas as distribucións en execución, así que garda o traballo primeiro.

Despois de reabrilo, confirma o xestor antes de tocar a unidade de OpenVPN: ps -p 1 -o comm= debería mostrar systemd. Activar systemd non achega ningún perfil, ningunha credencial e ningún nome de instancia, así que o seguinte erro tratará dun deses aspectos e non do PID 1.

Os contedores executan o seu punto de entrada, non unidades

Un contedor normal arrinca o que especifica o seu punto de entrada ou a súa orde, e non é unha máquina arrincada con systemd, instales os paquetes que instales. Engadir systemctl á imaxe dache un cliente sen nada ao que conectarse. En Community OpenVPN, o patrón admitido adoita ser un proceso en primeiro plano, openvpn --config /path/to/client.conf, iniciado polo punto de entrada e supervisado desde fóra. Ese propietario encárgase do arrinque, os sinais e o apagado, e debería ser o único que xestiona o túnel.

Nunca lances unha copia interactiva xunto a un punto de entrada que xa xestiona ese túnel, porque dous procesos pelexarán polo dispositivo e as rutas. Un proceso init mínimo dentro do contedor recolle os fillos e reenvía sinais; non converte a imaxe nun anfitrión con unidades.

Se un despregamento necesita de verdade systemd dentro dun contedor, necesita unha imaxe deseñada a propósito para iso, non privilexios adicionais engadidos ata que systemctl deixe de queixarse.

Le o seguinte erro cando exista o xestor

En canto un xestor real lanza o servizo, comezan os erros útiles. Un fallo de permisos do dispositivo, un erro de análise da configuración, unha credencial ausente e un par inalcanzable son catro problemas distintos que a mensaxe sobre PID 1 nunca probou. Léoos na orde en que os produciu a unidade, usando journalctl -u openvpn-client@office -n 50 nun anfitrión con systemd, ou executando o cliente en primeiro plano onde non hai ningún xestor. A execución en primeiro plano é tamén a forma máis rápida de confirmar que o propio perfil funciona.

Mantén os dous contornos separados nas túas notas: o anfitrión que executa o túnel e o lugar onde escribes ordes.

Artigos relacionados