Naprawa wpisu autostartu VPN, który uruchamia się tylko na jednym pulpicie

Klient VPN uruchamia się z menu aplikacji, tunel się łączy, a ikona nigdy nie pojawia się po zalogowaniu na jednej maszynie, podczas gdy ten sam pakiet zachowuje się poprawnie na innej. Trzy obserwacje zostają zlane w jedną skargę: czy program się uruchomił, czy jego interfejs jest widoczny i czy tunel jest podniesiony. Uruchamiaczem rządzi wpis pulpitu z kluczami filtrowania, a ten wpis nie ma nic wspólnego z protokołem VPN. Przejdź instrukcję po kolei i zatrzymaj się, gdy jedna z trzech rzeczy czysto się oddzieli.

Trzy osobne fakty: uruchomienie, ikona, tunel

Wpis pulpitu uruchamia program. Nie może zainstalować implementacji zasobnika i nie może sprawić, by wskaźnik pojawił się w panelu, który nie obsługuje protokołu używanego przez aplikację. Jeśli proces już działa, pytanie o uruchomienie ma odpowiedź i patrzysz raczej na problem integracji.

Tunel to znowu trzeci fakt. Brakująca ikona nie jest dowodem, że połączenie padło, a zabijanie i restartowanie klienta, by «naprawić» ikonę, to dokładnie ten sposób, w jaki działający tunel zostaje bez powodu przerwany. Użytkownicy zgłaszają brakującą ikonę i zepsuty tunel w tym samym zdaniu, i właśnie dlatego te dwie rzeczy trzeba rozdzielić na papierze.

Rozdziel je, zanim cokolwiek zmienisz. Sprawdź, czy proces istnieje, potem czy panel obsługuje wskaźnik, a na końcu czy interfejs zgłasza połączenie. Każda odpowiedź wskazuje inny poziom i innego właściciela.

Znajdź wpis, który sesja naprawdę czyta

Wpisy autostartu żyją w katalogu użytkownika i w katalogu systemowym, a gdy nazwy plików się zgadzają, wygrywa kopia użytkownika. Czytanie niewłaściwego to najczęstsza przyczyna tego, że zmiana wydaje się bez efektu. Wypisz oba katalogi, zanim cokolwiek edytujesz, i zanotuj, który plik sesja naprawdę załaduje.

ls -l ~/.config/autostart/ /etc/xdg/autostart/
echo "$XDG_CURRENT_DESKTOP"
grep -H -E '^(OnlyShowIn|NotShowIn|TryExec|Hidden|Exec)=' ~/.config/autostart/*.desktop /etc/xdg/autostart/*.desktop

Zmienna środowiskowa wypisuje nazwę sesji, z którą porównywane są klucze filtrowania, i zwykle jest to lista rozdzielona dwukropkami. Porównaj ją dosłownie z wartościami we wpisie, ponieważ te nazwy są wrażliwymi na wielkość liter szczegółami konfiguracji, a nie opisem sesji. Wartość GNOME nie pasuje do gnome, a powstała cisza nie ma dołączonego żadnego komunikatu o błędzie. Wypisz ją, zamiast zakładać.

Jeśli ta sama nazwa pliku istnieje w obu katalogach, liczy się kopia użytkownika. Edytowanie pliku systemowego i zastanawianie się, czemu nic się nie zmieniło, to bardzo częsta stracona godzina.

Czytaj klucze filtrowania, po kolei

Przykładowy wpis poniżej pokazuje klucze, które decydują, czy sesja uruchomi program. To fragment, a nie pełny uruchamiacz, i wartości należą do fikcyjnej ścieżki.

[Desktop Entry]
Type=Application
Name=Example VPN
Exec=/opt/example-vpn/client --minimized
TryExec=/opt/example-vpn/client
OnlyShowIn=GNOME;

OnlyShowIn ogranicza wpis do wymienionych środowisk, a NotShowIn wyklucza wymienione. Specyfikacja nie definiuje użytecznego zachowania, gdy oba występują w jednym wpisie, więc plik zawierający oba traktuj jako defekt, a nie sprytną kombinację. Usuń niepotrzebny klucz, zamiast dodawać drugi i liczyć na regułę pierwszeństwa.

TryExec pyta, czy plik wykonywalny istnieje, zanim sesja go uruchomi. Dlatego ścieżka pozostała po starszej instalacji tłumi autostart, nawet jeśli nowy pakiet działa przy uruchomieniu z menu, a ta awaria wygląda dokładnie jak filtr pulpitu.

Nadpisuj na poziomie użytkownika, nie systemu

Gdy filtr jest naprawdę niewłaściwy dla tej maszyny, skopiuj wpis systemowy do katalogu użytkownika i zmień kopię. Zgodnie z regułami autostartu XDG wpis użytkownika o tej samej nazwie ma pierwszeństwo, a Hidden=true wyłącza wpis bez usuwania pliku systemowego.

mkdir -p ~/.config/autostart
cp /etc/xdg/autostart/example-vpn.desktop ~/.config/autostart/
sed -i '/^OnlyShowIn=/d' ~/.config/autostart/example-vpn.desktop
desktop-file-validate ~/.config/autostart/example-vpn.desktop

Sprawdź wynik przed wylogowaniem, bo błędnie sformowany wpis jest po cichu ignorowany i następny test nic ci nie powie. Ponowna instalacja pakietu nie usunie twojego nadpisania, co jest celem i zarazem powodem, by odnotować, że ono istnieje. Zapisz ścieżkę pliku w zgłoszeniu, aby następna osoba znalazła nadpisanie, zamiast wyprowadzać je od nowa.

Wolij to od edytowania wspólnych uruchamiaczy systemowych, które zmienia zachowanie każdego użytkownika maszyny i nie podlega takiemu samemu przeglądowi. Nadpisanie na poziomie użytkownika jest widoczne w jednym miejscu, odwracalne przez usunięcie jednego pliku i łatwe do wyjaśnienia w zgłoszeniu. Plik systemowy pozostaje taki, jak dostarczył go dostawca, więc aktualizacja pakietu nie unieważnia po cichu twojego rozumowania.

Potwierdź uruchomienie, nie dotykając tunelu

Wyloguj się i zaloguj ponownie, a następnie potwierdź, że proces istnieje, zanim spojrzysz na panel. Udane uruchomienie i widoczna ikona to dwa różne wyniki, i tylko drugi wymaga pracy nad integracją z pulpitem. Mieszanie ich prowadzi do ponownej instalacji pakietu, który działał przez cały czas.

pgrep -af example-vpn
systemctl --user status example-vpn.service
journalctl --user -b --no-pager | grep -i example-vpn | tail -20

Jeśli procesu nie ma, przeczytaj wpis ponownie pod kątem pozostałego filtra lub nieaktualnej TryExec ścieżki. Jeśli jest, uruchamiacz zadziałał, a brakująca ikona to osobny problem z obsługą wskaźników przez panel, nie z wpisem, który właśnie edytowałeś.

Zapisz trzy obserwacje w zgłoszeniu: uruchomiony, widoczny, połączony. Ten zapis nie pozwala następnej osobie powtórzyć tego samego potrójnego zamieszania i pokazuje, która warstwa nadal wymaga pracy.