Linux에서 VPN 및 프록시 서비스를 순서대로 종료하기

프록시가 실행 중일 때 종료가 멈추는 것은 VPN 버그인 경우가 드물며, 화면에 마지막으로 보이는 것이 VPN이더라도 마찬가지입니다. 프록시 뒤의 애플리케이션은 곧 사라질 경로를 여전히 기다리고 있고, 터널을 소유한 유닛은 아직 그것을 닫으라는 요청을 받지 않았습니다. 느린 서비스처럼 보이는 것은 보통 순서 문제입니다. 순서를 정하는 것이 어떤 타임아웃 변경보다 이런 경우를 더 많이 해결합니다.

반대 순서로 바깥쪽으로 진행하세요: 소비자 먼저, 그다음 프록시, 마지막으로 터널 — 각각은 그것을 시작한 구성 요소가 중지합니다.

무엇이든 중지하기 전에 유닛 목록을 만드세요

정상 실행에 관련된 애플리케이션 유닛, 프록시 유닛, VPN 소유자를 적어 두세요. 자체 종료가 있는 리졸버나 도우미 구성 요소도 추가하세요. 새벽 두 시에 잊히는 것이 바로 그것들이기 때문입니다. 그 목록이 없으면 당신이 입력하는 첫 중지 명령이 무작위로 희생자를 고릅니다.

이름은 약한 증거입니다. 사용자 프록시, 시스템 프록시, 다른 계정의 터널은 같은 이름을 공유하면서도 수명 주기는 전혀 무관할 수 있습니다.

먼저 작업을 끝내고, 그다음 소비자를 중지하세요

계획된 중지는 애플리케이션에서 시작합니다: 요청을 완료하거나 취소하게 한 다음, 서비스 유닛을 통해 프록시를 중지하세요. 터널이 사라진 뒤에도 애플리케이션이 계속 실행되어야 한다면, 곧 사라질 경로에 붙여 두는 대신 의도적으로 마련하세요.

중지 중에 진행 중이던 요청은 다음 시작에서 재시도 폭풍이 바로 그곳에서 나오기 때문에 기록에 속합니다.

ExecStop과 ExecStopPost는 다른 도구입니다

ExecStop= — 이것은 동기식 중지 작업입니다; ExecStopPost= — 이것은 시작이 실패한 뒤에도 실행되는 정리입니다. 프로세스에 신호만 보내고 돌아오는 중지 명령은 소비자가 여전히 데이터를 비우는 동안 systemd가 계속 진행하게 둡니다. 무슨 일이 있어도 일어나야 하는 것은 사후 변형에, 중지를 막아야 하는 것은 동기식 변형에 속합니다. 패키지 파일을 그 자리에서 편집하는 대신 실제 적용되는 유닛과 그 drop-in 파일을 확인하세요.

의존성 그래프는 중지 작업의 순서를 정합니다. 비동기 스크립트를 동기식으로 바꾸지도 않고, 원격 애플리케이션이 데이터를 커밋하도록 강제하지도 않습니다.

중지를 제한하고 그 제한의 비용을 알아두세요

TimeoutStopSec= 중지 명령과 서비스 자체의 종료를 모두 제한하며, 제한이 만료되면 systemd는 강제 kill로 단계를 높입니다. 값은 애플리케이션의 실제 플러시 동작에서 고르고, 제한에 도달할 때 무엇이 손실될 수 있는지 적어 두세요. 머신이 더 빨리 꺼져야 한다는 이유로 고른 숫자는 다른 이름의 데이터 손실 설정입니다.

중지가 여전히 느리면 유닛, 그 자식 프로세스, journal 간격, 타임아웃 결과를 기록하세요. 모든 타임아웃을 줄이거나 광범위한 kill에 손을 뻗는 것이 깨끗한 중지가 다음 부팅에서 손상된 상태가 되는 방식입니다.

소유자를 통해 연결을 끊고, 그다음 세 가지 경우를 시험하세요

소비자가 내려간 뒤 터널을 소유한 관리자에게 연결 해제를 요청하세요: systemd 인스턴스, NetworkManager 활성 연결, 또는 공급업체 서비스. 무관한 OpenVPN 프로세스를 죽인다고 경로를 제공한 세션이 반드시 제거되지는 않으며, 재시작 정책이 있는 프록시는 당신이 경로를 해체하는 동안 요청을 다시 만들 수 있습니다. 시작하기 전에 그 정책을 계획된 중지와 조정하세요.

정상 중지, 활성 요청이 있는 중지, 터널이 먼저 실패하는 중지를 시험하세요. 기한이 있는 반복 가능한 순서가 한 번만 통하는 빠른 종료보다 낫습니다.