systemctl Says systemd Is Not PID 1: Then What?

Running systemctl start openvpn-client@office and getting a message about the system not having been booted with systemd reads like a service failure. It is not a service failure at all: the systemctl you invoked cannot find a running manager to talk to, so nothing about OpenVPN was ever examined. sudo does not create a manager, and installing a unit file does not either. The command and the machine come from two different worlds, and the error is the only place that showed up.

Start by asking which process owns PID 1 where the command runs, since that answer decides whether units exist at all.

The Error Names the Environment, Not OpenVPN

systemctl is a client, not a manager. It connects to the system manager over a socket, and when there is no manager at the other end it prints the message people paste into forums. ps -p 1 -o pid=,comm= shows what actually runs as PID 1, and the answer is often a shell, an init wrapper, or the container's own entrypoint. In that situation a unit file may be perfectly valid and still never be read. Repeating the command as root changes only the credentials of the client.

Read the whole message before the first line. An error from the manager itself, such as a missing unit or a failed condition, means you reached one; this error means you did not.

WSL: Enabling systemd Is a Config Change

WSL gained systemd support in later releases, but the feature is enabled per distribution and only where the installed WSL version supports it. wsl --version on the Windows side reports what you have, and the distribution's /etc/wsl.conf carries a [boot] section with systemd=true. Edit that file without dropping the sections already present, then restart the WSL instance so the change takes effect. wsl --shutdown stops every running distribution, so save work first.

After reopening, confirm the manager before touching the OpenVPN unit: ps -p 1 -o comm= should report systemd. Turning systemd on supplies no profile, no credential and no instance name, so the next error will concern one of those rather than PID 1.

Containers Run Their Entrypoint, Not Units

A normal container starts whatever its entrypoint or command specifies, and it is not a systemd-booted machine no matter which packages you install. Adding systemctl to the image gives you a client with nothing to connect to. For Community OpenVPN the supported pattern is usually a foreground process, openvpn --config /path/to/client.conf, started by the entrypoint and supervised from outside. That owner handles startup, signals and shutdown, and it should be the only thing managing the tunnel.

Never launch an interactive copy next to an entrypoint that already manages that tunnel, because two processes will fight over the device and the routes. A minimal init process inside the container reaps children and forwards signals; it does not turn the image into a host with units.

If a deployment genuinely needs systemd inside a container, it needs a deliberately designed image for that, not extra privileges added until systemctl stops complaining.

Read the Next Error Once the Manager Exists

Once a real manager launches the service, the useful errors begin. A device permission failure, a configuration parse error, a missing credential and an unreachable peer are four different problems that the PID 1 message never tested. Read them in the order the unit produced them, using journalctl -u openvpn-client@office -n 50 on a systemd host, or by running the client in the foreground where no manager exists. The foreground run is also the quickest way to confirm that the profile itself works.

Keep the two environments separate in your notes: the host that runs the tunnel, and the place where you type commands.