-.mount 유닛이 마스크되어 있습니다: OpenVPN 클라이언트가 시작되지 않습니다
/run/systemd/system에 남은 -.mount 파일이 루트 마운트 유닛을 마스크하므로, 파일 시스템이 필요한 모든 유닛이 OpenVPN이 시작되기 전에 실패합니다.
서비스는 OpenVPN이 실행되기도 전에 실패하고, 오류는 설정한 적 없는 마운트 유닛을 이야기합니다. 이것이 단서입니다. 루트 마운트 유닛이 마스크되어 있어 systemd가 트랜잭션 전체를 거부하고 있고, VPN 프로필은 아직 읽히지 않았습니다. 흔한 원인은 런타임 유닛 디렉터리에 남은 파일이며, 망가진 fstab도 아니고 빠진 인증서도 아닙니다. 먼저 파일을 따라가 보세요. 배제하기에 가장 저렴한 설명입니다.
오류는 루트 마운트를 지목하지, 당신의 프로필이 아닙니다
systemd는 커널의 마운트 정보로 루트 마운트 유닛을 스스로 만들고, 하이픈이 루트 경로를 뜻하기 때문에 그 유닛을 -.mount이라고 부릅니다. 이 유닛은 보통 메모리에만 존재하고 뒤에 파일이 없습니다. 오류가 마스크되었다고 말할 때는 누군가가 systemd가 읽어 들일 위치에 유닛 파일을 두고 그 파일을 /dev/null로 향하게 한 것입니다. 마스크는 실제 상태이며 메시지의 오타가 아닙니다.
인스턴스 유닛이 실패하는 이유는 작업 그래프가 정렬과 자체 마운트 요구를 통해 루트 마운트에 도달하기 때문입니다. 트랜잭션은 OpenVPN 바이너리가 실행되기 전에 거부되므로 클라이언트 설정 어디에도 원인이 있을 수 없습니다. 그래서 프로필, 인증서, 자격 증명을 바꿔도 이 특정 실패에는 영향이 없습니다.
OpenVPN을 디버깅하기 전에 런타임 디렉터리를 확인하세요
런타임 유닛 디렉터리에서 정확히 그 이름의 파일을 찾고, 그다음 systemd에게 유닛이 무엇이라고 생각하는지 물어보세요. 두 답은 모두 빠르고, 함께 남은 파일과 진짜 마운트 문제를 구분합니다.
ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount
일반적인 머신에는 그런 파일이 없고, 마스크된 목록에 루트 마운트가 없습니다. 첫 명령이 /dev/null에 대한 심볼릭 링크를 출력하면 진단은 확정입니다. 같은 디렉터리에 같은 도구가 만든 tmp.mount 마스크가 있을 수도 있고, 그것은 다른 이름으로 같은 종류의 실패를 만듭니다. 오류에 나온 이름만 보지 말고 디렉터리 전체를 보세요.
ls -la /run/systemd/system/*.mount
디렉터리가 깨끗한데 유닛이 여전히 마스크되어 있다면 마스크는 검색 경로의 다른 곳에 있고, systemctl cat -.mount이 어떤 파일이 로드되는지 보여 줍니다.
파일을 삭제하고 다시 로드한 뒤 다시 시작하세요
런타임 파일을 지우고 관리자를 다시 로드하면 충분하며, 패키지에서 온 어떤 것도 건드리지 않습니다. 시작 전에 다시 로드하세요. systemd는 디렉터리를 다시 읽을 때까지 로드된 유닛 상태를 유지합니다.
sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]
그다음 고쳐졌다고 가정하지 말고 서비스 자체의 저널을 읽으세요. 깨끗한 시작은 systemd가 유닛을 받아들였다는 것만 증명합니다. 클라이언트는 빠진 프로필, 닿을 수 없는 피어, 검증되지 않는 인증서 때문에 여전히 죽을 수 있습니다. 그것들은 마스크된 유닛 뒤에 숨어 있던 평범한 OpenVPN 문제입니다. 저널은 어떤 프로필이 로드되었고 터널이 실제로 수립되었는지 기록합니다. 유닛은 시작되고 터널이 서지 않는다면 다른 문제로 넘어간 것이고, 그것이 진전입니다.
journalctl -u [email protected] -b --no-pager
/run는 임시 파일 시스템이므로 재부팅도 파일을 지웁니다. 그래서 재부팅은 유용한 시험이 됩니다. 재부팅 뒤에는 동작하고 다음 배포 뒤에 다시 실패한다면 그 파일은 이미지에 구워지고 있는 것입니다.
이미지에서 다시 돌아오지 못하게 하세요
빌드 중에 마운트 유닛을 마스크하는 컨테이너나 가상 머신 템플릿은 그 마스크를 모든 클론으로 가져갑니다. 다음으로 파일 시스템이 필요한 것이 깨지고, 메시지는 출처인 이미지 대신 마운트를 탓합니다. 실행 중인 한 인스턴스 안에서 고치면 다음 인스턴스가 만들어질 때까지 문제가 숨겨집니다.
빌드 컨텍스트에서 파일 이름과 그것을 만드는 명령을 찾고, 템플릿에서 마스크를 제거한 뒤 다시 빌드하세요. 빌드 중에 마스크가 정말 필요하다면 빌드를 끝내는 같은 레이어에서 제거해, 배포되는 이미지가 깨끗하게 시작하도록 하세요. 손으로 고친 머신이 아니라 새 클론에서 검증하세요. 이미지가 바뀌었음을 증명하는 유일한 시험입니다.
기억해야 할 증상은 오류와 당신이 설정하던 것 사이의 불일치입니다. systemd가 마운트를 문제 삼는데 당신이 VPN 클라이언트를 시작하는 중이라면, 먼저 메시지의 유닛 이름을 읽고 그다음 서비스 이름을 읽으세요.