Исправление записи автозапуска VPN, которая работает только на одном рабочем столе

Клиент VPN запускается из меню приложений, туннель подключается, а значок так и не появляется после входа на одной машине, тогда как тот же пакет ведёт себя нормально на другой. Три наблюдения сваливаются в одну жалобу: запустилась ли программа, виден ли её интерфейс и поднят ли туннель. Лаунчером управляет запись рабочего стола с ключами фильтрации, и эта запись не имеет никакого отношения к протоколу VPN. Пройдите инструкцию по порядку и остановитесь, когда одно из трёх чётко отделится.

Три отдельных факта: запуск, значок, туннель

Запись рабочего стола запускает программу. Она не может установить реализацию лотка и не может заставить индикатор появиться на панели, которая не поддерживает протокол, используемый приложением. Если процесс уже работает, вопрос о запуске закрыт, и вы смотрите скорее на проблему интеграции.

Туннель — это снова третий факт. Отсутствующий значок не является доказательством того, что соединение упало, а убийство и перезапуск клиента, чтобы «починить» значок, — это именно тот способ, которым рабочий туннель прерывается без причины. Пользователи сообщают об отсутствующем значке и сломанном туннеле в одном предложении, и именно поэтому эти две вещи нужно разделить на бумаге.

Разделите их, прежде чем что-то менять. Проверьте, существует ли процесс, затем поддерживает ли панель индикатор и наконец сообщает ли интерфейс о соединении. Каждый ответ указывает на другой слой и другого ответственного.

Найдите запись, которую сеанс действительно читает

Записи автозапуска находятся в каталоге пользователя и в системном каталоге, и при совпадении имён файлов побеждает пользовательская копия. Чтение неправильной записи — самая частая причина того, что изменение выглядит без эффекта. Перечислите оба каталога, прежде чем что-либо редактировать, и отметьте, какой файл сеанс действительно загрузит.

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

Переменная окружения выводит имя сеанса, с которым сравниваются ключи фильтрации, и обычно это список, разделённый двоеточиями. Сравните его буквально со значениями в записи, потому что эти имена — чувствительные к регистру детали конфигурации, а не описание сеанса. Значение GNOME не совпадает с gnome, а возникшая тишина не сопровождается никаким сообщением об ошибке. Выведите его, а не предполагайте.

Если одно и то же имя файла есть в обоих каталогах, важна пользовательская копия. Редактировать системный файл и удивляться, почему ничего не изменилось, — очень часто потерянный час.

Читайте ключи фильтрации по порядку

Иллюстративная запись ниже показывает ключи, которые решают, запустит ли сеанс программу. Это фрагмент, а не полный лаунчер, и значения относятся к вымышленному пути.

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

OnlyShowIn ограничивает запись перечисленными средами, а NotShowIn исключает перечисленные. Спецификация не определяет полезного поведения, когда оба встречаются в одной записи, поэтому файл с обоими считайте дефектом, а не умной комбинацией. Удалите ненужный ключ вместо того, чтобы добавлять второй и надеяться на правило приоритета.

TryExec спрашивает, существует ли исполняемый файл, прежде чем сеанс его запустит. Поэтому путь, оставшийся от более старой установки, подавляет автозапуск, даже если новый пакет работает при запуске из меню, и этот сбой выглядит точно как фильтр рабочего стола.

Переопределяйте на уровне пользователя, а не системы

Когда фильтр действительно неверен для этой машины, скопируйте системную запись в каталог пользователя и измените копию. Согласно правилам автозапуска XDG, пользовательская запись с тем же именем имеет приоритет, а Hidden=true отключает запись, не удаляя системный файл.

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

Проверьте результат, прежде чем выходить из системы, потому что некорректно оформленная запись молча игнорируется и следующий тест вам ничего не скажет. Переустановка пакета не удалит ваше переопределение, в этом и смысл, и в этом же причина записать, что оно существует. Укажите путь к файлу в заявке, чтобы следующий человек нашёл переопределение, а не выводил его заново.

Предпочитайте это редактированию общих системных лаунчеров, которое меняет поведение для каждого пользователя машины и не подлежит такой же проверке. Переопределение на уровне пользователя видно в одном месте, обратимо удалением одного файла и легко объясняется в заявке. Системный файл остаётся таким, каким его отправил поставщик, поэтому обновление пакета молча не отменяет ваши рассуждения.

Подтвердите запуск, не трогая туннель

Выйдите и войдите снова, затем подтвердите, что процесс существует, прежде чем смотреть на панель. Успешный запуск и видимый значок — два разных результата, и только второй требует работы по интеграции с рабочим столом. Их смешение отправляет вас переустанавливать пакет, который работал всё это время.

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

Если процесса нет, перечитайте запись на предмет оставшегося фильтра или устаревшего TryExec пути. Если он есть, лаунчер сработал, и отсутствующий значок — отдельная проблема с поддержкой индикаторов панелью, а не с записью, которую вы только что отредактировали.

Запишите три наблюдения в заявку: запущен, виден, подключён. Эта запись не даст следующему человеку повторить ту же тройную путаницу и покажет, какому слою ещё нужна работа.