systemctl dice que systemd no es PID 1: ¿y ahora qué?
El mensaje sobre PID 1 habla del entorno, no de OpenVPN. Comprueba qué se ejecuta como PID 1, activa systemd donde sea compatible y lee después el error real.
Ejecutar systemctl start openvpn-client@office y recibir un mensaje de que el sistema no se ha iniciado con systemd parece un fallo del servicio. No es ningún fallo del servicio: el systemctl que has invocado no encuentra ningún gestor en ejecución con el que hablar, así que no se examinó nada relacionado con OpenVPN. sudo no crea un gestor, y tampoco lo crea instalar un archivo de unidad. La orden y la máquina vienen de dos mundos distintos, y el error es el único lugar donde eso se hizo visible.
Empieza preguntando qué proceso posee el PID 1 allí donde se ejecuta la orden, porque esa respuesta decide si las unidades existen siquiera.
El error nombra el entorno, no OpenVPN
systemctl es un cliente, no un gestor. Se conecta al gestor del sistema mediante un socket y, cuando no hay ningún gestor al otro lado, imprime el mensaje que la gente pega en los foros. ps -p 1 -o pid=,comm= muestra qué se ejecuta realmente como PID 1, y la respuesta suele ser un shell, un envoltorio init o el punto de entrada propio del contenedor. En esa situación, un archivo de unidad puede ser perfectamente válido y aun así no leerse nunca. Repetir la orden como root solo cambia las credenciales del cliente.
Lee el mensaje completo antes de la primera línea. Un error del propio gestor, como una unidad ausente o una condición fallida, significa que llegaste a uno; este error significa que no.
WSL: activar systemd es un cambio de configuración
WSL obtuvo soporte para systemd en versiones posteriores, pero la función se activa por distribución y solo donde la versión instalada de WSL la admite. wsl --version en el lado de Windows indica qué tienes, y el /etc/wsl.conf de la distribución contiene [boot] una sección con systemd=true. Edita ese archivo sin eliminar las secciones que ya están, y luego reinicia la instancia de WSL para que el cambio surta efecto. wsl --shutdown detiene todas las distribuciones en ejecución, así que guarda el trabajo primero.
Después de reabrirlo, confirma el gestor antes de tocar la unidad de OpenVPN: ps -p 1 -o comm= debería mostrar systemd. Activar systemd no aporta ningún perfil, ninguna credencial y ningún nombre de instancia, así que el siguiente error tratará de uno de esos aspectos y no del PID 1.
Los contenedores ejecutan su punto de entrada, no unidades
Un contenedor normal arranca lo que especifica su punto de entrada o su orden, y no es una máquina arrancada con systemd, instales los paquetes que instales. Añadir systemctl a la imagen te da un cliente sin nada a lo que conectarse. En Community OpenVPN, el patrón admitido suele ser un proceso en primer plano, openvpn --config /path/to/client.conf, iniciado por el punto de entrada y supervisado desde fuera. Ese propietario se encarga del arranque, las señales y el apagado, y debería ser lo único que gestiona el túnel.
Nunca lances una copia interactiva junto a un punto de entrada que ya gestiona ese túnel, porque dos procesos se pelearán por el dispositivo y las rutas. Un proceso init mínimo dentro del contenedor recoge a los hijos y reenvía señales; no convierte la imagen en un anfitrión con unidades.
Si un despliegue necesita de verdad systemd dentro de un contenedor, necesita una imagen diseñada a propósito para ello, no privilegios adicionales añadidos hasta que systemctl deje de quejarse.
Lee el siguiente error cuando exista el gestor
En cuanto un gestor real lanza el servicio, empiezan los errores útiles. Un fallo de permisos del dispositivo, un error de análisis de la configuración, una credencial ausente y un par inalcanzable son cuatro problemas distintos que el mensaje sobre PID 1 nunca probó. Léelos en el orden en que los produjo la unidad, usando journalctl -u openvpn-client@office -n 50 en un anfitrión con systemd, o ejecutando el cliente en primer plano donde no hay ningún gestor. La ejecución en primer plano es también la forma más rápida de confirmar que el propio perfil funciona.
Mantén los dos entornos separados en tus notas: el anfitrión que ejecuta el túnel y el lugar donde escribes órdenes.