A VPN-kliens elindul az alkalmazásmenüből, az alagút csatlakozik, és az ikon soha nem jelenik meg bejelentkezés után az egyik gépen, miközben ugyanaz a csomag a másikon rendesen viselkedik. Három megfigyelés olvad össze egyetlen panaszba: elindult-e a program, látható-e a felülete, és áll-e az alagút. Az indítót szűrőkulcsokkal rendelkező asztali bejegyzés szabályozza, és ennek a bejegyzésnek semmi köze a VPN protokollhoz. Haladjunk végig az útmutatón sorrendben, és álljunk meg, amikor a három közül valamelyik tisztán elválik.

Három külön tény: indítás, ikon, alagút

Az asztali bejegyzés elindít egy programot. Nem tud tálcamegoldást telepíteni, és nem tud jelzőt megjeleníteni olyan panelen, amely nem támogatja az alkalmazás által használt protokollt. Ha a folyamat már fut, az indítás kérdése megválaszolódott, és helyette integrációs problémát látunk.

Az alagút megint egy harmadik tény. A hiányzó ikon nem bizonyítéka a kapcsolat megszakadásának, és a kliens leölése majd újraindítása az ikon «javításáért» pontosan az a mód, ahogyan egy működő alagút ok nélkül megszakad. A felhasználók a hiányzó ikont és a törött alagutat ugyanabban a mondatban említik, és épp ezért kell a kettőt papíron szétválasztani.

Válasszuk szét őket, mielőtt bármit változtatunk. Ellenőrizzük, létezik-e a folyamat, aztán hogy a panel támogatja-e a jelzőt, végül hogy a felület jelent-e kapcsolatot. Minden válasz más rétegre és más felelősre mutat.

Keressük meg a bejegyzést, amelyet a munkamenet ténylegesen olvas

Az automatikus indítási bejegyzések a felhasználói könyvtárban és a rendszerkönyvtárban élnek, és ha a fájlnevek megegyeznek, a felhasználói példány győz. A rossz bejegyzés olvasása a leggyakoribb oka annak, hogy egy változtatás hatástalannak látszik. Mindkét könyvtárat listázzuk ki, mielőtt bármit szerkesztünk, és jegyezzük fel, melyik fájlt tölti be a munkamenet valójában.

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

A környezeti változó azt a munkamenetnevet írja ki, amelyhez a szűrőkulcsokat hasonlítják, és ez általában kettőspontokkal tagolt lista. Hasonlítsuk össze szó szerint a bejegyzés értékeivel, mert ezek a nevek kis- és nagybetűérzékeny konfigurációs részletek, nem a munkamenet leírása. Egy GNOME érték nem egyezik a gnome értékkel, és az ebből fakadó csendhez semmilyen hibaüzenet nem társul. Írassuk ki, ahelyett hogy feltételeznénk.

Ha ugyanaz a fájlnév mindkét könyvtárban megtalálható, a felhasználói példány számít. A rendszerfájl szerkesztése és azon való csodálkozás, hogy miért nem változott semmi, nagyon gyakori elvesztegetett óra.

Olvassuk a szűrőkulcsokat, sorrendben

Az alábbi szemléltető bejegyzés azokat a kulcsokat mutatja, amelyek eldöntik, elindítja-e a munkamenet a programot. Ez töredék, nem teljes indító, és az értékek egy kitalált útvonalhoz tartoznak.

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

OnlyShowIn a bejegyzést a felsorolt környezetekre korlátozza, és NotShowIn kizárja a felsoroltakat. A specifikáció nem határoz meg hasznos viselkedést, ha mindkettő szerepel egy bejegyzésben, ezért a mindkettőt tartalmazó fájlt hibának tekintsük, nem okos kombinációnak. Távolítsuk el a szükségtelen kulcsot, ahelyett hogy hozzáadnánk a másodikat és elsőbbségi szabályban reménykednénk.

TryExec azt kérdezi, létezik-e a futtatható fájl, mielőtt a munkamenet elindítaná. Ezért egy régebbi telepítésből visszamaradt útvonal elnyomja az automatikus indítást akkor is, ha az új csomag a menüből indítva működik, és ez a hiba pontosan úgy néz ki, mint egy asztali szűrő.

Felhasználói szinten írjuk felül, ne rendszerszinten

Amikor a szűrő valóban rossz ehhez a géphez, másoljuk a rendszerbejegyzést a felhasználói könyvtárba, és módosítsuk a példányt. Az XDG automatikus indítási szabályai szerint az azonos nevű felhasználói bejegyzésnek elsőbbsége van, és Hidden=true letilt egy bejegyzést a rendszerfájl törlése nélkül.

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

Hitelesítsük az eredményt, mielőtt kijelentkezünk, mert a hibás bejegyzést csendben figyelmen kívül hagyják, és a következő teszt semmit nem mond. A csomag újratelepítése nem távolítja el a felülírást, ez a lényeg, és ez az oka annak is, hogy feljegyezzük a létezését. Jegyezzük fel a fájl útvonalát a jegyben, hogy a következő ember megtalálja a felülírást, ne pedig újra levezesse.

Ezt részesítsük előnyben a megosztott rendszerindítók szerkesztésével szemben, amely minden felhasználó viselkedését megváltoztatja a gépen, és nem vizsgálható ugyanúgy. A felhasználói szintű felülírás egy helyen látható, egy fájl törlésével visszafordítható, és jegyben könnyen elmagyarázható. A rendszerfájl úgy marad, ahogy a szállító kiszállította, így egy csomagfrissítés nem vonja vissza csendben az érvelésünket.

Erősítsük meg az indítást anélkül, hogy az alagúthoz nyúlnánk

Jelentkezzünk ki és vissza, majd erősítsük meg, hogy a folyamat létezik, mielőtt a panelre nézünk. A sikeres indítás és a látható ikon két különböző eredmény, és csak a másodikhoz kell asztali integrációs munka. Ha összekeverjük őket, olyan csomagot telepítünk újra, amely végig működött.

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

Ha a folyamat hiányzik, olvassuk újra a bejegyzést maradék szűrő vagy elavult TryExec útvonal után kutatva. Ha jelen van, az indító működött, és a hiányzó ikon külön probléma a panel jelzőtámogatásával, nem azzal a bejegyzéssel, amelyet épp szerkesztettünk.

Jegyezzük fel a három megfigyelést a jegyben: elindult, látható, csatlakozva. Ez a feljegyzés megakadályozza, hogy a következő ember ugyanazt a hármas zavart megismételje, és világossá teszi, melyik réteg szorul még munkára.

Kapcsolódó cikkek