Виправлення запису автозапуску VPN, який працює лише на одному робочому столі
Засіб запуску VPN, який стартує на одному робочому столі і не стартує на іншому, — це фільтр у записі робочого стола, а не збій тунелю. Спершу прочитайте OnlyShowIn, TryExec і перевизначення.
Клієнт 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 шляху. Якщо він є, засіб запуску спрацював, і відсутній значок — окрема проблема з підтримкою індикаторів панелі, а не із записом, який ви щойно редагували.
Запишіть три спостереження в заявку: запущено, видно, підключено. Цей запис не дасть наступній людині повторити ту саму потрійну плутанину і покаже, якому шару ще потрібна робота.