systemctl говорит, что systemd — не PID 1: и что дальше?

Если systemctl start openvpn-client@office запускается и появляется сообщение о том, что система загружена не с systemd, это выглядит как сбой службы. Но это вовсе не сбой службы: systemctl, который вы вызвали, не находит работающего менеджера, с которым можно поговорить, поэтому ничего про OpenVPN проверено не было. sudo не создаёт менеджера, и установка файла unit тоже его не создаёт. Команда и машина происходят из двух разных миров, и ошибка — единственное место, где это проявилось.

Начните с вопроса, какой процесс владеет PID 1 там, где выполняется команда, потому что этот ответ определяет, существуют ли unit-файлы вообще.

Ошибка называет окружение, а не OpenVPN

systemctl — это клиент, а не менеджер. Он подключается к системному менеджеру через сокет, и когда на другом конце менеджера нет, выводит то самое сообщение, которое люди вставляют на форумах. ps -p 1 -o pid=,comm= показывает, что на самом деле работает как PID 1, и ответом часто оказывается оболочка, обёртка init или собственная точка входа контейнера. В такой ситуации файл unit может быть совершенно корректным и всё равно никогда не прочитанным. Повтор команды от root меняет только учётные данные клиента.

Прочитайте всё сообщение целиком, прежде чем первую строку. Ошибка от самого менеджера, например отсутствующий unit или невыполненное условие, значит, что вы до него добрались; эта ошибка значит, что нет.

WSL: включение systemd — это изменение конфигурации

WSL получил поддержку systemd в более поздних выпусках, но функция включается для каждого дистрибутива отдельно и только там, где её поддерживает установленная версия WSL. wsl --version на стороне Windows показывает, что у вас есть, а /etc/wsl.conf дистрибутива содержит [boot] раздел с systemd=true. Отредактируйте этот файл, не удаляя уже имеющиеся разделы, затем перезапустите экземпляр WSL, чтобы изменение вступило в силу. wsl --shutdown останавливает каждый работающий дистрибутив, поэтому сначала сохраните работу.

После повторного открытия подтвердите менеджер, прежде чем трогать unit OpenVPN: ps -p 1 -o comm= должен показать systemd. Включение systemd не даёт ни профиля, ни учётных данных, ни имени экземпляра, поэтому следующая ошибка будет про одно из этого, а не про PID 1.

Контейнеры запускают свою точку входа, а не unit-файлы

Обычный контейнер запускает то, что задаёт его точка входа или команда, и он не является машиной, загруженной с systemd, какие бы пакеты вы ни ставили. Добавление systemctl в образ даёт вам клиент, которому не к чему подключиться. Для Community OpenVPN поддерживаемый шаблон — обычно процесс на переднем плане, openvpn --config /path/to/client.conf, запускаемый точкой входа и контролируемый снаружи. Этот владелец отвечает за запуск, сигналы и остановку, и он должен быть единственным, кто управляет туннелем.

Никогда не запускайте интерактивную копию рядом с точкой входа, которая уже управляет этим туннелем, потому что два процесса начнут бороться за устройство и маршруты. Минимальный процесс init внутри контейнера собирает потомков и передаёт сигналы; он не превращает образ в хост с unit-файлами.

Если развёртыванию действительно нужен systemd внутри контейнера, ему нужен намеренно спроектированный образ, а не дополнительные привилегии, которые добавляют, пока systemctl не перестанет жаловаться.

Читайте следующую ошибку, когда менеджер уже есть

Как только настоящий менеджер запускает службу, начинаются полезные ошибки. Отказ в правах на устройство, ошибка разбора конфигурации, отсутствующие учётные данные и недоступный партнёр — это четыре разные проблемы, которые сообщение о PID 1 никогда не проверяло. Читайте их в том порядке, в котором их создал unit, с помощью journalctl -u openvpn-client@office -n 50 на хосте с systemd или запустив клиент на переднем плане там, где менеджера нет. Запуск на переднем плане — ещё и самый быстрый способ убедиться, что сам профиль работает.

Держите два окружения отдельно в своих заметках: хост, который запускает туннель, и место, где вы набираете команды.