Reparera en VPN-autostartpost som bara körs på ett skrivbord

VPN-klienten startar från programmenyn, tunneln ansluter och ikonen dyker aldrig upp efter inloggning på en maskin, medan samma paket beter sig korrekt på en annan. Tre observationer pressas samman till ett enda klagomål: om programmet startade, om gränssnittet syns och om tunneln är uppe. Startaren styrs av en skrivbordspost med filtreringsnycklar, och den posten har ingenting med VPN-protokollet att göra. Gå igenom vägledningen i ordning och stanna när en av de tre skiljs ut rent.

Tre åtskilda fakta: start, ikon, tunnel

En skrivbordspost startar ett program. Den kan inte installera en fackimplementering, och den kan inte få en indikator att dyka upp i en panel som inte stöder protokollet programmet använder. Om processen redan körs är startfrågan besvarad och du tittar i stället på ett integrationsproblem.

Tunneln är återigen ett tredje faktum. En saknad ikon är inte bevis för att anslutningen föll, och att döda och starta om klienten för att «reparera» ikonen är precis hur en fungerande tunnel avbryts utan anledning. Användare rapporterar den saknade ikonen och den trasiga tunneln i samma mening, och det är just därför de två måste skiljas åt på papper.

Skilj dem innan du ändrar något. Kontrollera om processen finns, sedan om panelen stöder indikatorn och till sist om gränssnittet rapporterar en anslutning. Varje svar pekar på ett annat lager och en annan ägare.

Hitta posten som sessionen faktiskt läser

Autostartposter ligger i användarkatalogen och i systemkatalogen, och när filnamnen är lika vinner användarkopian. Att läsa fel post är den vanligaste orsaken till att en ändring verkar sakna effekt. Lista båda katalogerna innan du redigerar något och notera vilken fil sessionen faktiskt kommer att läsa in.

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

Miljövariabeln skriver ut sessionsnamnet som filtreringsnycklarna jämförs med, och det är vanligtvis en kolonavgränsad lista. Jämför den bokstavligt med värdena i posten, eftersom dessa namn är skiftlägeskänsliga konfigurationsdetaljer och inte en beskrivning av sessionen. Ett värde GNOME matchar inte gnome, och den resulterande tystnaden har inget felmeddelande kopplat till sig. Skriv ut den i stället för att anta den.

Om samma filnamn finns i båda katalogerna är det användarkopian som gäller. Att redigera systemfilen och undra varför ingenting ändrades är en mycket vanlig förlorad timme.

Läs filtreringsnycklarna, i ordning

Exempelposten nedan visar nycklarna som avgör om en session startar programmet. Det är ett fragment, inte en komplett startare, och värdena tillhör en fiktiv sökväg.

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

OnlyShowIn begränsar posten till de angivna miljöerna och NotShowIn utesluter de angivna. Specifikationen definierar inget användbart beteende när båda förekommer i en post, så behandla en fil med båda som en defekt och inte som en smart kombination. Ta bort nyckeln du inte behöver i stället för att lägga till den andra och hoppas på en prioritetsregel.

TryExec frågar om den körbara filen finns innan sessionen startar den. En sökväg som blivit kvar från en äldre installation undertrycker därför autostart även om det nya paketet fungerar när det startas från menyn, och det felet ser precis ut som ett skrivbordsfilter.

Överstyr på användarnivå, inte på systemnivå

När filtret verkligen är fel för den här maskinen, kopiera systemposten till användarkatalogen och ändra kopian. Enligt XDG:s autostartregler har en användarpost med samma namn företräde, och Hidden=true inaktiverar en post utan att radera systemfilen.

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

Validera resultatet innan du loggar ut, eftersom en felformad post ignoreras tyst och nästa test inte säger dig något. Att installera om paketet tar inte bort din överstyrning, vilket är poängen och också anledningen att anteckna att den finns. Skriv filvägen i ärendet så att nästa person hittar överstyrningen i stället för att härleda den igen.

Föredra detta framför att redigera delade systemstartare, som ändrar beteendet för varje användare på maskinen och inte kan granskas på samma sätt. En överstyrning på användarnivå syns på ett ställe, är reversibel genom att radera en fil och är lätt att förklara i ett ärende. Systemfilen förblir som leverantören skickade den, så en paketuppdatering upphäver inte ditt resonemang i tysthet.

Bekräfta starten utan att röra tunneln

Logga ut och in igen och bekräfta sedan att processen finns innan du tittar på panelen. En lyckad start och en synlig ikon är två olika resultat, och bara det andra kräver arbete med skrivbordsintegration. Att blanda ihop dem skickar dig att installera om ett paket som fungerade hela tiden.

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

Om processen saknas, läs posten igen efter ett kvarvarande filter eller en inaktuell TryExec sökväg. Om den finns fungerade startaren och den saknade ikonen är ett separat problem med panelens indikatorstöd, inte med posten du just redigerade.

Anteckna de tre observationerna i ärendet: startad, synlig, ansluten. Den anteckningen hindrar nästa person från att upprepa samma tredubbla förvirring och gör klart vilket lager som fortfarande behöver arbete.