Rett opp en VPN-autostartoppføring som bare kjører på én skrivebordsøkt

VPN-klienten starter fra programmenyen, tunnelen kobles til, og ikonet dukker aldri opp etter innlogging på én maskin, mens den samme pakken oppfører seg riktig på en annen. Tre observasjoner presses sammen til én klage: om programmet startet, om grensesnittet er synlig, og om tunnelen er oppe. Starteren styres av en skrivebordsoppføring med filtreringsnøkler, og den oppføringen har ingenting med VPN-protokollen å gjøre. Gå gjennom veiledningen i rekkefølge, og stopp når én av de tre skiller seg rent ut.

Tre atskilte fakta: start, ikon, tunnel

En skrivebordsoppføring starter et program. Den kan ikke installere en skuffimplementasjon, og den kan ikke få en indikator til å dukke opp i et panel som ikke støtter protokollen programmet bruker. Hvis prosessen allerede kjører, er startspørsmålet besvart, og du ser i stedet på et integrasjonsproblem.

Tunnelen er igjen et tredje faktum. Et manglende ikon er ikke bevis for at forbindelsen falt, og å drepe og starte klienten på nytt for å «reparere» ikonet er nettopp måten en fungerende tunnel avbrytes uten grunn. Brukere rapporterer det manglende ikonet og den ødelagte tunnelen i samme setning, og derfor må de to skilles på papiret.

Skill dem før du endrer noe. Sjekk om prosessen finnes, deretter om panelet støtter indikatoren, og til slutt om grensesnittet rapporterer en forbindelse. Hvert svar peker på et annet lag og en annen eier.

Finn oppføringen økten faktisk leser

Autostartoppføringer ligger i brukerkatalogen og i systemkatalogen, og når filnavnene er like, vinner brukerkopien. Det å lese feil oppføring er den vanligste årsaken til at en endring ser ut til å ikke ha effekt. List begge katalogene før du redigerer noe, og noter hvilken fil økten faktisk vil laste.

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øvariabelen skriver ut øktnavnet som filtreringsnøklene sammenlignes med, og det er vanligvis en kolonadelt liste. Sammenlign den bokstavelig med verdiene i oppføringen, fordi disse navnene er store og små bokstaver-følsomme konfigurasjonsdetaljer og ikke en beskrivelse av økten. En verdi GNOME samsvarer ikke med gnome, og stillheten som følger har ingen feilmelding knyttet til seg. Skriv den ut i stedet for å anta den.

Hvis det samme filnavnet finnes i begge katalogene, er det brukerkopien som teller. Å redigere systemfilen og lure på hvorfor ingenting endret seg er en svært vanlig tapt time.

Les filtreringsnøklene, i rekkefølge

Den illustrative oppføringen nedenfor viser nøklene som avgjør om en økt starter programmet. Det er et fragment, ikke en komplett starter, og verdiene tilhører en fiktiv sti.

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

OnlyShowIn begrenser oppføringen til de angitte miljøene, og NotShowIn utelukker de angitte. Spesifikasjonen definerer ikke nyttig atferd når begge forekommer i én oppføring, så behandle en fil med begge som en feil og ikke som en smart kombinasjon. Fjern nøkkelen du ikke trenger i stedet for å legge til den andre og håpe på en prioritetsregel.

TryExec spør om den kjørbare filen finnes før økten starter den. En sti som er igjen fra en eldre installasjon undertrykker derfor autostart selv om den nye pakken virker når den startes fra menyen, og den feilen ser nøyaktig ut som et skrivebordsfilter.

Overstyr på brukernivå, ikke på systemnivå

Når filteret virkelig er feil for denne maskinen, kopier systemoppføringen til brukerkatalogen og endre kopien. Etter XDG-reglene for autostart har en brukeroppføring med samme navn forrang, og Hidden=true deaktiverer en oppføring uten å slette 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

Valider resultatet før du logger ut, fordi en feilformet oppføring ignoreres i stillhet og den neste testen ikke forteller deg noe. Å installere pakken på nytt fjerner ikke overstyringen din, som er poenget og også grunnen til å notere at den finnes. Skriv filstien i saken slik at neste person finner overstyringen i stedet for å utlede den på nytt.

Foretrekk dette fremfor å redigere delte systemstartere, som endrer atferd for hver bruker på maskinen og ikke kan gjennomgås på samme måte. En overstyring på brukernivå er synlig på ett sted, reversibel ved å slette én fil, og lett å forklare i en sak. Systemfilen forblir slik leverandøren sendte den, så en pakkeoppdatering opphever ikke resonnementet ditt i stillhet.

Bekreft starten uten å røre tunnelen

Logg ut og inn igjen, og bekreft deretter at prosessen finnes før du ser på panelet. En vellykket start og et synlig ikon er to forskjellige resultater, og bare det andre krever arbeid med skrivebordsintegrasjon. Å blande dem sender deg ut for å installere på nytt en pakke som virket hele tiden.

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

Hvis prosessen mangler, les oppføringen på nytt for et gjenværende filter eller en utdatert TryExec sti. Hvis den er til stede, virket starteren, og det manglende ikonet er et separat problem med panelets indikatorstøtte, ikke med oppføringen du nettopp redigerte.

Noter de tre observasjonene i saken: startet, synlig, tilkoblet. Det notatet hindrer neste person i å gjenta den samme tredelte forvirringen og gjør det klart hvilket lag som fortsatt trenger arbeid.