Réparer une entrée de démarrage automatique VPN qui ne se lance que sur un seul bureau

Le client VPN démarre depuis le menu des applications, le tunnel se connecte, et l'icône n'apparaît jamais après la connexion sur une machine, alors que le même paquet se comporte normalement sur une autre. Trois observations sont écrasées en une seule plainte : si le programme s'est lancé, si son interface est visible et si le tunnel est actif. Le lanceur est régi par une entrée de bureau dotée de clés de filtrage, et cette entrée n'a rien à voir avec le protocole VPN. Parcourez la procédure dans l'ordre et arrêtez-vous quand l'un des trois se sépare proprement.

Trois faits distincts : lancement, icône, tunnel

Une entrée de bureau lance un programme. Elle ne peut pas installer une implémentation de zone de notification et elle ne peut pas faire apparaître un indicateur dans un panneau qui ne prend pas en charge le protocole utilisé par l'application. Si le processus tourne déjà, la question du lancement est réglée et vous regardez plutôt un problème d'intégration.

Le tunnel est encore un troisième fait. Une icône absente n'est pas la preuve que la connexion est tombée, et tuer puis redémarrer le client pour « réparer » l'icône est précisément la façon dont un tunnel qui fonctionne est interrompu sans raison. Les utilisateurs signalent l'icône absente et le tunnel cassé dans la même phrase, et c'est exactement pourquoi les deux doivent être séparés sur le papier.

Séparez-les avant de changer quoi que ce soit. Vérifiez si le processus existe, puis si le panneau prend en charge l'indicateur, puis si l'interface signale une connexion. Chaque réponse désigne une couche différente et un responsable différent.

Trouvez l'entrée que la session lit réellement

Les entrées de démarrage automatique vivent dans le répertoire de l'utilisateur et dans le répertoire système, et lorsque les noms de fichiers correspondent, la copie de l'utilisateur l'emporte. Lire la mauvaise est la raison la plus fréquente pour laquelle un changement semble sans effet. Listez les deux répertoires avant de modifier quoi que ce soit et notez quel fichier la session chargera réellement.

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

La variable d'environnement affiche le nom de session auquel les clés de filtrage sont comparées, et c'est généralement une liste séparée par des deux-points. Comparez-la littéralement aux valeurs de l'entrée, car ces noms sont des détails de configuration sensibles à la casse et non une description de la session. Une valeur GNOME ne correspond pas à gnome, et le silence qui en résulte n'est accompagné d'aucun message d'erreur. Affichez-la au lieu de la supposer.

Si le même nom de fichier existe dans les deux répertoires, c'est la copie de l'utilisateur qui compte. Modifier le fichier système et se demander pourquoi rien n'a changé est une heure perdue très courante.

Lisez les clés de filtrage, dans l'ordre

L'entrée illustrative ci-dessous montre les clés qui décident si une session lance le programme. C'est un fragment, pas un lanceur complet, et les valeurs appartiennent à un chemin fictif.

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

OnlyShowIn restreint l'entrée aux environnements listés et NotShowIn exclut ceux qui sont listés. La spécification ne définit pas de comportement utile lorsque les deux apparaissent dans une même entrée, alors traitez un fichier contenant les deux comme un défaut et non comme une combinaison astucieuse. Supprimez la clé dont vous n'avez pas besoin au lieu d'ajouter la seconde en espérant une règle de priorité.

TryExec demande si l'exécutable existe avant que la session ne le lance. Un chemin resté d'une installation plus ancienne supprime donc le démarrage automatique même si le nouveau paquet fonctionne lorsqu'on le lance depuis le menu, et cette panne ressemble exactement à un filtre de bureau.

Remplacez au niveau de l'utilisateur, pas au niveau du système

Lorsque le filtre est réellement erroné pour cette machine, copiez l'entrée système dans le répertoire de l'utilisateur et modifiez la copie. Selon les règles de démarrage automatique XDG, une entrée utilisateur de même nom a la priorité, et Hidden=true désactive une entrée sans supprimer le fichier système.

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

Validez le résultat avant de vous déconnecter, car une entrée mal formée est ignorée en silence et le test suivant ne vous apprend rien. Réinstaller le paquet ne supprimera pas votre substitution, ce qui est le but et aussi la raison de consigner qu'elle existe. Notez le chemin du fichier dans le ticket pour que la personne suivante trouve la substitution au lieu de la redéduire.

Préférez ceci à la modification de lanceurs système partagés, qui change le comportement de chaque utilisateur de la machine et n'est pas vérifiable de la même manière. Une substitution au niveau de l'utilisateur est visible à un seul endroit, réversible en supprimant un fichier et facile à expliquer dans un ticket. Le fichier système reste tel que le fournisseur l'a livré, si bien qu'une mise à jour du paquet n'annule pas silencieusement votre raisonnement.

Confirmez le lancement sans toucher au tunnel

Déconnectez-vous puis reconnectez-vous, et confirmez ensuite que le processus existe avant de regarder le panneau. Un lancement réussi et une icône visible sont deux résultats différents, et seul le second demande un travail d'intégration au bureau. Les confondre vous envoie réinstaller un paquet qui fonctionnait depuis le début.

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

Si le processus est absent, relisez l'entrée à la recherche d'un filtre restant ou d'un chemin TryExec obsolète. S'il est présent, le lanceur a fonctionné et l'icône manquante est un problème distinct lié à la prise en charge des indicateurs par le panneau, non à l'entrée que vous venez de modifier.

Consignez les trois observations dans le ticket : lancé, visible, connecté. Cette trace empêche la personne suivante de répéter la même confusion triple et indique clairement quelle couche demande encore du travail.