새 VPN 바로가기가 사라진 설정을 되돌리지 못하는 이유

누락된 메뉴 항목과 사라지는 설정은 같은 반사로 고쳐지곤 하지만 서로 무관한 문제입니다. 하나는 데스크톱 통합이고 다른 하나는 애플리케이션 상태이며, 새 아이콘은 그 자체로 둘 다 바꾸지 않습니다. 둘을 분리하는 데는 실험 하나면 충분하고, 이 주제에 사람들이 가져오는 혼란의 대부분이 설명됩니다. 실행기는 프로그램을 시작하고, 무엇을 기억할지는 프로그램이 정합니다.

하나처럼 보이는 두 가지 일

데스크톱 통합은 환경이 실행 파일을 찾고 이름과 아이콘을 표시하며 올바른 인수를 전달할 수 있다는 뜻입니다. 애플리케이션 상태는 프로그램이 프로필을 지속되는 위치에 쓰고 다음 시작 때 다시 읽는다는 뜻입니다. 어느 것도 다른 하나를 함의하지 않으므로, 동작하는 바로가기가 모든 것을 잊은 클라이언트를 실행할 수 있습니다.

애플리케이션 자체의 제어를 통해 무해한 표시 설정 하나를 바꾼 뒤, 같은 방식으로 닫았다가 다시 여세요. 설정이 돌아오면 지속성이 동작하며 남은 불만은 데이터 저장이 아니라 창을 찾는 문제입니다. 사라진다면 바로가기는 주의를 돌리는 것이고, 진짜 질문은 그 프로세스가 파일을 어디에 두는가입니다. 한 번에 설정 하나씩 시험해 보세요, 비밀번호를 다시 묻는 클라이언트는 구성을 잃는 것이 아니라 비밀을 지키고 있는 것일 수 있습니다.

재설치 전에 시작 입력을 비교하세요

데스크톱 항목에서 시작해 그것이 실제로 무엇을 하는지 읽어 보세요, 메뉴에서 시작하는 것이 터미널에서 시작하는 것과 자동으로 같은 프로세스 환경은 아니기 때문입니다. 중요한 키는 Exec, Path, 그리고 간접적으로 세션이 제공하는 환경입니다. Exec 안의 래퍼 스크립트는 변수를 설정하거나, 디렉터리를 바꾸거나, 메뉴가 결코 보여 주지 않는 권한 있는 도우미를 호출할 수 있습니다. 재설치는 애플리케이션이 이미 갖고 있던 파일을 교체하며, 그것이 바뀐 변수인 경우는 드뭅니다.

grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop

~/.local/share/applications 아래의 파일을 /usr/share/applications 안의 파일보다 먼저 보세요, 사용자 사본이 시스템 사본을 가리기 때문입니다. 항목이 잘못 동작하면 desktop-file-validate 을 실행하고, 삭제된 경로를 가리키는 오래된 사본이 있는지 찾아보세요. 유효하지 않은 사용자 사본도 대부분의 데스크톱은 여전히 선호하므로, 깨진 파일이 메뉴에서 항목을 없앨 수 있는 반면 패키지의 파일은 유효하게 남습니다. 그다음 같은 명령을 직접 실행해 두 시작이 무엇을 만드는지 비교하세요.

설정이 실제로 사는 곳

XDG 기본 디렉터리 규칙을 따르는 애플리케이션은 구성을 $XDG_CONFIG_HOME 아래에, 지속 상태를 $XDG_STATE_HOME 아래에, 일회성 데이터를 $XDG_CACHE_HOME 아래에 두며, 그 변수가 설정되지 않았을 때 기본값으로 ~/.config, ~/.local/state, ~/.cache 를 사용합니다. 이 셋은 약속이 아니라 역할이므로 특정 VPN 제품은 전혀 다른 것을 문서화할 수 있습니다. 디렉터리 이름에서 경로를 추측하기보다 공급업체 자체 문서를 읽는 편이 낫습니다. 문서가 빈약하면 파일 시스템이 아니라 프로세스를 관찰하세요.

파일 열기에 맞춰 필터링한 추적은 클라이언트가 시도하는 모든 구성 경로를, 종료할 때 쓰는 경로까지 포함해 보여 줍니다. 같은 사용자와 같은 환경으로 실행한 뒤, 그 경로를 예상했던 디렉터리와 비교하세요.

strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client

비밀과 프로필의 소유자는 다릅니다

저장된 프로필과 저장된 자격 증명은 별개의 객체이며 대개 별도의 저장소를 갖습니다. 하나는 구성 파일에 살고 다른 하나는 세션마다 잠금이 풀리는 키링에 앉아 있을 수 있으므로, 비밀번호를 다시 묻는 클라이언트는 설계된 대로 동작하는 것일 수 있습니다. 물음을 멈추려고 프로필을 지우는 것이 사람들이 동작하던 구성을 잃는 길입니다.

권한 있는 시작은 이를 더 복잡하게 만듭니다, 왜냐하면 sudo나 PolicyKit 도우미를 통한 시작은 다른 홈 디렉터리를, 따라서 다른 구성 집합을 제시할 수 있기 때문입니다. 홈 디렉터리 전체에 재귀적으로 적용하지 말고 애플리케이션이 문서화한 특정 파일에서 소유권을 바로잡은 뒤, 앞으로 어떤 정체성이 프로필을 소유해야 하는지 정하고 이후 시작을 그것과 일관되게 유지하세요.

아이콘이 알려 줄 수 있는 것과 없는 것

아이콘은 실행기 파일이 해결된다는 것만 증명하며 그 이상은 아닙니다. 연결 상태는 클라이언트의 것이므로, 신뢰할 수 있는 확인은 인터페이스, 경로, 또는 클라이언트 자체의 상태 출력뿐입니다. 시작하지 못한 트레이 애플릿은 동작하는 터널을 끊어진 것처럼 보이게 하고, 오래된 애플릿은 끊어진 터널을 멀쩡해 보이게 할 수 있습니다. 연결과 실행기를 따로 시험한 뒤 실제로 어느 쪽을 고쳤는지 적어 두세요.

둘 다 고장 났다면 수리를 하나의 변경으로 다루려는 유혹을 물리치세요. 항목을 고치고 시작을 확인한 뒤 터널을 확인하고, 각 단계의 결과를 기록하세요. 그 기록이 다음번 사라진 설정 보고를 이번 일의 반복이 아니라 진단 가능한 것으로 만들고, 문제의 어느 절반이 진짜였는지 다음 사람에게 알려 줍니다.