Einen VPN-Autostart-Eintrag reparieren, der nur auf einem Desktop startet

Der VPN-Client startet aus dem Anwendungsmenü, der Tunnel verbindet, und das Symbol erscheint nach der Anmeldung auf einem Rechner nie, während sich dasselbe Paket auf einem anderen Rechner normal verhält. Drei Beobachtungen werden in eine Beschwerde zusammengezogen: ob das Programm gestartet ist, ob seine Oberfläche sichtbar ist und ob der Tunnel steht. Der Starter wird von einem Desktop-Eintrag mit Filterschlüsseln gesteuert, und dieser Eintrag hat nichts mit dem VPN-Protokoll zu tun. Arbeiten Sie die Anleitung der Reihe nach durch und hören Sie auf, sobald sich eine der drei Fragen sauber trennen lässt.

Drei getrennte Fakten: Start, Symbol, Tunnel

Ein Desktop-Eintrag startet ein Programm. Er kann keine Tray-Implementierung installieren, und er kann kein Indikator-Symbol in einem Panel erscheinen lassen, das das Protokoll der Anwendung nicht unterstützt. Läuft der Prozess bereits, ist die Startfrage beantwortet und Sie sehen stattdessen ein Integrationsproblem.

Der Tunnel ist wiederum ein dritter Fakt. Ein fehlendes Symbol ist kein Beweis dafür, dass die Verbindung abgebrochen ist, und den Client zu beenden und neu zu starten, um das Symbol zu „reparieren“, ist genau die Art, wie ein funktionierender Tunnel ohne Grund unterbrochen wird. Nutzer melden das fehlende Symbol und den kaputten Tunnel im selben Satz, und genau deshalb müssen die beiden auf dem Papier getrennt werden.

Trennen Sie sie, bevor Sie etwas ändern. Prüfen Sie, ob der Prozess existiert, dann ob das Panel den Indikator unterstützt und schließlich ob die Oberfläche eine Verbindung meldet. Jede Antwort zeigt auf eine andere Schicht und einen anderen Verantwortlichen.

Finden Sie den Eintrag, den die Sitzung tatsächlich liest

Autostart-Einträge liegen im Benutzerverzeichnis und im Systemverzeichnis, und bei gleichen Dateinamen gewinnt die Benutzerkopie. Den falschen Eintrag zu lesen ist der häufigste Grund, warum eine Änderung wirkungslos zu sein scheint. Listen Sie beide Verzeichnisse auf, bevor Sie etwas bearbeiten, und notieren Sie, welche Datei die Sitzung tatsächlich lädt.

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

Die Umgebungsvariable gibt den Sitzungsnamen aus, mit dem die Filterschlüssel verglichen werden, und das ist meist eine durch Doppelpunkte getrennte Liste. Vergleichen Sie ihn wörtlich mit den Werten im Eintrag, denn diese Namen sind groß- und kleinschreibungssensitive Konfigurationsdetails und keine Beschreibung der Sitzung. Ein Wert GNOME stimmt nicht mit gnome überein, und die daraus folgende Stille hat keine Fehlermeldung. Geben Sie ihn aus, statt ihn anzunehmen.

Existiert derselbe Dateiname in beiden Verzeichnissen, zählt die Benutzerkopie. Die Systemdatei zu bearbeiten und sich zu fragen, warum sich nichts geändert hat, ist eine sehr verbreitete verlorene Stunde.

Lesen Sie die Filterschlüssel, der Reihe nach

Der beispielhafte Eintrag unten zeigt die Schlüssel, die entscheiden, ob eine Sitzung das Programm startet. Er ist ein Fragment, kein vollständiger Starter, und die Werte gehören zu einem fiktiven Pfad.

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

OnlyShowIn beschränkt den Eintrag auf die aufgeführten Umgebungen und NotShowIn schließt die aufgeführten aus. Die Spezifikation definiert kein sinnvolles Verhalten, wenn beide in einem Eintrag stehen, behandeln Sie eine Datei mit beiden daher als Defekt und nicht als kluge Kombination. Entfernen Sie den Schlüssel, den Sie nicht brauchen, statt den zweiten hinzuzufügen und auf eine Vorrangregel zu hoffen.

TryExec fragt, ob die ausführbare Datei existiert, bevor die Sitzung sie startet. Ein Pfad aus einer älteren Installation unterdrückt den Autostart daher, obwohl das neue Paket beim Start aus dem Menü funktioniert, und dieser Fehler sieht genau wie ein Desktop-Filter aus.

Auf Benutzerebene überschreiben, nicht auf Systemebene

Wenn der Filter für diesen Rechner wirklich falsch ist, kopieren Sie den Systemeintrag in das Benutzerverzeichnis und ändern Sie die Kopie. Nach den XDG-Autostart-Regeln hat ein Benutzereintrag mit gleichem Namen Vorrang, und Hidden=true deaktiviert einen Eintrag, ohne die Systemdatei zu löschen.

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

Validieren Sie das Ergebnis, bevor Sie sich abmelden, denn ein fehlerhafter Eintrag wird stillschweigend ignoriert und der nächste Test sagt Ihnen nichts. Eine Neuinstallation des Pakets entfernt Ihre Überschreibung nicht, was der Sinn und zugleich der Grund ist, ihr Vorhandensein festzuhalten. Notieren Sie den Dateipfad im Ticket, damit die nächste Person die Überschreibung findet, statt sie erneut herzuleiten.

Bevorzugen Sie dies gegenüber dem Bearbeiten gemeinsamer Systemstarter, das das Verhalten für jeden Benutzer des Rechners ändert und sich nicht in gleicher Weise überprüfen lässt. Eine Überschreibung auf Benutzerebene ist an einer Stelle sichtbar, durch Löschen einer Datei rückgängig zu machen und in einem Ticket leicht zu erklären. Die Systemdatei bleibt, wie der Hersteller sie ausgeliefert hat, sodass ein Paketupdate Ihre Überlegung nicht stillschweigend rückgängig macht.

Bestätigen Sie den Start, ohne den Tunnel anzufassen

Melden Sie sich ab und wieder an, und bestätigen Sie dann, dass der Prozess existiert, bevor Sie das Panel ansehen. Ein erfolgreicher Start und ein sichtbares Symbol sind zwei verschiedene Ergebnisse, und nur das zweite braucht Arbeit an der Desktop-Integration. Verwechselt man sie, landet man bei der Neuinstallation eines Pakets, das die ganze Zeit funktioniert hat.

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

Fehlt der Prozess, lesen Sie den Eintrag erneut auf einen verbliebenen Filter oder einen veralteten TryExec Pfad. Ist er vorhanden, hat der Starter funktioniert, und das fehlende Symbol ist ein separates Problem mit der Indikatorunterstützung des Panels, nicht mit dem Eintrag, den Sie gerade bearbeitet haben.

Halten Sie die drei Beobachtungen im Ticket fest: gestartet, sichtbar, verbunden. Diese Aufzeichnung hindert die nächste Person daran, dieselbe dreifache Verwirrung zu wiederholen, und macht klar, welche Schicht noch Arbeit braucht.