무언가가 OpenVPN 유닛을 반복해서 시작하고 있습니다: 출처를 찾으세요

OpenVPN 인스턴스가 부팅 시 낯선 이름으로 올라오고, 중지해도 다음 재부팅까지만 유효합니다. 이 패턴은 프로세스는 제거했지만 활성화는 남아 있다는 뜻입니다. 둘은 다른 객체이고 상태 화면에는 하나만 보입니다. 활성화를 찾으려면 읽기 전용 명령 네 개와 한 가지 판단이 필요합니다.

먼저 정확한 유닛을 지목하세요

프로필 파일 이름이 아니라 journal의 유닛 이름에서 시작하세요. 인스턴스 이름은 openvpn@, openvpn-client@, openvpn-server@ 또는 배포판 특유의 이름일 수 있으며, 이름을 추측하면 잘못된 템플릿으로 갑니다. 상태 출력은 실제로 실행된 유닛을 표시하며, 여기서 중요한 유일한 이름입니다. 접미사를 포함해 그대로 복사하세요.

다음 명령은 아무것도 바꾸지 않고 그 유닛을 설명합니다. systemctl show는 프래그먼트 경로, 소스 경로, 유닛 파일 상태, 모든 drop-in, 그리고 무엇이 이를 트리거했는지 보고합니다. list-dependencies --reverse는 어떤 로드된 유닛이 그것을 가리키는지 보여 줍니다. 둘 다 읽기 전용이므로 이론을 세우기 전에 실행하세요.

관찰된 이름을 모든 곳에서 바꾸세요. 복사한 예시 이름은 잘못된 서비스를 조사하는 가장 흔한 방법이며, 한 번도 실행되지 않은 유닛에 대해 자신감 있는 답변을 내놓습니다.

템플릿을 읽어 파일 이름을 알아내세요

인스턴스 유닛은 템플릿의 확장이며, 어떤 구성 파일을 읽는지는 템플릿이 결정합니다(어떤 구성 파일을 읽는지). 인스턴스별 자리 표시자로 끝나는 명령줄은 인스턴스 이름과 접미사로 해석됩니다. 접미사가 .conf이고 인스턴스 이름이 old이면 파일은 old.conf입니다. 인스턴스 이름을 old.conf로 하면 같은 템플릿이 old.conf.conf를 요구합니다.

그 세부 사항이 중복의 한 종류를 설명합니다. 누군가 잘못된 이름으로 두 번째 인스턴스를 추가하고, 첫 번째는 계속 실행되며, 호스트에는 터널 두 개와 혼란스러운 로그 하나가 남습니다.

편집했다고 기억하는 파일이 아니라 실제로 유효한 템플릿을 읽으세요. drop-in이 명령줄을 대체할 수 있고, 부팅 시 실행되는 것은 그 대체본입니다.

그것이 부팅 트랜잭션에 어떻게 들어가는지 추적하세요

세 가지 경로가 흔합니다: 타깃에서 오는 wants 링크, 다른 유닛에서 오는 요구, 패키지 생성기가 만드는 생성 유닛입니다. 역종속 목록은 앞의 두 가지를 로드된 그래프 항목으로 포함합니다. 타이머, 훅, 외부 요청은 포함하지 않으므로 이 목록은 완전한 감사가 아니라 증거입니다.

/run/systemd/generator 아래의 생성된 출력은 제품이며 출처가 아닙니다. 편집은 다음 생성까지만 유지되므로, 거기에 적용한 수정은 성공한 것처럼 보였다가 되돌아갑니다.

생성기가 어디에서 읽는지 가정하기 전에 패키지의 문서화된 입력을 확인하세요. 문서화되지 않은 디렉터리 스캔이 유닛이 활성화 링크 없이 나타나는 흔한 이유입니다.

활성화를 제거하고 프로세스만 다루지 마세요

인스턴스가 직접 활성화되어 있고 정말로 폐기 대상이라면, systemctl disable --now가 중지와 부팅 링크 제거를 한 단계로 수행합니다. 먼저 이 터널이 호스트로 가는 유일한 관리 경로가 아닌지 확인하세요. 이 명령은 수명 주기의 예시이며, 머신의 모든 VPN을 중지하라는 제안이 아닙니다. 확인은 명령 전에 하고, 후에 하지 마세요.

두 부분은 분리 가능하며 자주 혼동됩니다. 비활성화는 실행 중인 서비스를 중지하지 않고, 중지는 활성화를 제거하지 않으므로, 부분 명령은 부팅 시 재발하는 문제를 설명합니다.

비활성화된 유닛도 다른 유닛이나 명시적 요청으로 시작될 수 있습니다. 생성기가 활성화를 소유한다면 출력을 비활성화하는 대신 입력을 고치세요. 마스킹은 더 많은 경로를 막지만 종속성을 깨뜨릴 수 있으므로 이해를 대신하지 않습니다.

상태 화면이 아니라 재부팅으로 검증하세요

유닛 정의나 생성기 입력이 바뀌었다면 systemd를 다시 로드한 뒤 결과 상태를 확인하세요. 데몬 다시 로드는 실행 중인 터널에 새 프로필을 밀어 넣지 않으므로 두 확인은 별개입니다. 재부팅을 예약하고, 의도한 터널이 계속 동작하는 동안 인스턴스가 없음을 확인하세요.

이전 프로필은 소유 관계가 파악될 때까지 보관하고, 그다음 의도된 절차로 폐기하세요. 성공은 존재하지 않는 유닛과 작동하는 접근 경로이며, 한 화면에서 사라진 실패 유닛이 아닙니다.