Reparar unha entrada de inicio automático de VPN que só se executa nun escritorio

O cliente VPN arrinca desde o menú de aplicacións, o túnel conéctase e a icona nunca aparece tras iniciar sesión nun equipo, mentres que o mesmo paquete compórtase ben noutro. Tres observacións funden nunha única queixa: se o programa se lanzou, se a súa interface é visible e se o túnel está activo. O lanzador réxese por unha entrada de escritorio con claves de filtrado, e esa entrada non ten nada que ver co protocolo VPN. Percorre o manual en orde e detente cando unha das tres cousas se separe con claridade.

Tres feitos separados: arrinque, icona, túnel

Unha entrada de escritorio lanza un programa. Non pode instalar unha implementación de bandexa e non pode facer que apareza un indicador nun panel que non admite o protocolo que usa a aplicación. Se o proceso xa se está executando, a pregunta do arrinque está respondida e o que tes diante é un problema de integración.

O túnel é un terceiro feito. Unha icona ausente non é proba de que a conexión se cortase, e matar e reiniciar o cliente para «arranxar» a icona é xusto como se interrompe un túnel que funciona sen motivo ningún. Os usuarios relatan a icona ausente e o túnel roto na mesma frase, e por iso mesmo hai que separar ambos sobre o papel.

Sepáraos antes de cambiar nada. Comproba se o proceso existe, logo se o panel admite o indicador e por último se a interface informa dunha conexión. Cada resposta apunta a unha capa distinta e a un responsable distinto.

Atopa a entrada que a sesión le de verdade

As entradas de inicio automático viven no directorio do usuario e no directorio do sistema, e cando os nomes de ficheiro coinciden gaña a copia do usuario. Ler a que non toca é o motivo máis habitual de que un cambio pareza non ter efecto. Lista ambos os directorios antes de editar nada e anota que ficheiro cargará realmente a sesión.

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 variable de contorno imprime o nome de sesión co que se comparan as claves de filtrado, que adoita ser unha lista separada por dous puntos. Compáraa literalmente cos valores da entrada, porque eses nomes son detalles de configuración sensibles a maiúsculas e non unha descrición da sesión. Un valor GNOME non coincide con gnome, e o silencio resultante non leva ningunha mensaxe de erro. Imprímaa en lugar de supoñela.

Se o mesmo nome de ficheiro existe en ambos os directorios, a copia do usuario é a que importa. Editar o ficheiro do sistema e preguntarse por que non cambiou nada é unha hora perdida moi habitual.

Le as claves de filtrado, en orde

A entrada ilustrativa de abaixo mostra as claves que deciden se unha sesión lanza o programa. É un fragmento, non un lanzador completo, e os valores pertencen a unha ruta ficticia.

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

OnlyShowIn restrinxe a entrada aos contornos enumerados e NotShowIn exclúe os enumerados. A especificación non define un comportamento útil cando ambos aparecen nunha mesma entrada, así que trata un ficheiro que conteña os dous como un defecto e non como unha combinación enxeñosa. Elimina a clave que non necesites en lugar de engadir a segunda e confiar nunha regra de precedencia.

TryExec pregunta se o executábel existe antes de que a sesión o lance. Por iso unha ruta que quedou dunha instalación anterior suprime o inicio automático aínda que o paquete novo funcione ao inicialo desde o menú, e ese fallo parece exactamente un filtro de escritorio.

Anula a nivel de usuario, non a nivel de sistema

Cando o filtro é realmente incorrecto para este equipo, copia a entrada do sistema ao directorio do usuario e cambia a copia. Segundo as regras de inicio automático XDG, unha entrada de usuario co mesmo nome ten precedencia, e Hidden=true desactiva unha entrada sen borrar o ficheiro do sistema.

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

Valida o resultado antes de pechar a sesión, porque unha entrada mal formada ignórase en silencio e a seguinte proba non che di nada. Reinstalar o paquete non eliminará a túa anulación, que é o obxectivo e tamén o motivo de deixar constancia de que existe. Anota a ruta do ficheiro no tícket para que a seguinte persoa atope a anulación en lugar de volver deducila.

Prefire isto a editar lanzadores compartidos do sistema, que cambian o comportamento de todos os usuarios do equipo e non se poden revisar do mesmo xeito. Unha anulación a nivel de usuario é visible nun só lugar, reversible borrando un ficheiro e fácil de explicar nun tícket. O ficheiro do sistema queda como o enviou o provedor, así que unha actualización do paquete non desfai o teu razoamento en silencio.

Confirma o arrinque sen tocar o túnel

Pecha a sesión e volve entrar, logo confirma que o proceso existe antes de mirar o panel. Un arrinque correcto e unha icona visible son dous resultados distintos, e só o segundo necesita traballo de integración co escritorio. Mesturalos lévaos a reinstalar un paquete que funcionaba todo o tempo.

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

Se o proceso non está, volve ler a entrada por se queda algún filtro ou unha ruta TryExec obsoleta. Se está, o lanzador funcionou e a icona ausente é un problema á parte co soporte de indicadores do panel, non coa entrada que acabas de editar.

Anota as tres observacións no tícket: iniciado, visible, conectado. Ese rexistro evita que a seguinte persoa repita a mesma confusión tripla e deixa claro que capa aínda necesita traballo.