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 은 실행 중인 모든 배포판을 중지하므로 먼저 작업을 저장하세요.

다시 연 뒤에는 OpenVPN unit을 건드리기 전에 관리자를 확인하세요: 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 호스트에서 사용하거나, 관리자가 없는 곳에서 클라이언트를 포그라운드로 실행해서 읽으면 됩니다. 포그라운드 실행은 프로필 자체가 동작하는지 확인하는 가장 빠른 방법이기도 합니다.

메모에서 두 환경을 분리해 두세요. 터널을 실행하는 호스트와, 명령을 입력하는 장소입니다.