apt purge видалив VPN, але служба все одно запускається під час завантаження

apt purge каже, що пакета немає, а тунель усе одно піднімається під час кожного запуску. Journal продовжує рости, маршрути повертаються, і машина поводиться так, ніби нічого не видаляли. Інсталятор постачальника може записувати файли, які менеджер пакетів ніколи не обліковував, тому видалити пакет і видалити продукт це дві різні роботи. Runbook нижче розділяє два записи й навмисно завершує видалення.

Два інсталятори, два різні записи

Пакети Debian зберігають список файлів, і purge видаляє саме те, що названо в списку, плюс конфігурацію пакета. Інсталятор shell або набір .run такого списку не має; він пише куди завгодно, зазвичай у /opt, /usr/local і /etc/systemd/system. Жоден із цих шляхів не зявляється в списку файлів жодного пакета, тому dpkg про них не знає й не повідомляє. У підсумку на одній файловій системі два власники встановлення, і лише один із них веде облік.

Запитайте dpkg про конкретний шлях, перш ніж його видаляти. Шлях, від якого він відмовляється, ваш для видалення, і та сама відповідь скаже, чи поверне його пізніше оновлення.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

Unit і його wants-посилання це окремі файли

Увімкнення це окрема дія від встановлення. Unit оголошує звязки з цілями в розділі [Install], і systemctl enable перетворює ці оголошення на символічні посилання в каталозі .wants/ кожної цілі. Тепер є два шляхи: файл unit і посилання, яке втягує його в ціль завантаження. Видаліть лише файл, і посилання вказує в порожнечу, що дає скаргу під час завантаження; видаліть лише посилання, і unit залишається запускним за назвою. Піти має й те й те.

Видаліть їх по черзі й потім перезавантажте, щоб systemd перестав тримати старі визначення в памяті.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Читайте FragmentPath замість того, щоб припускати розташування, бо постачальник міг записати в /usr/lib/systemd/system або /lib/systemd/system, а не в /etc. Видалення очікуваної копії залишає чинну працювати, і виправлення виглядає успішним до наступного перезавантаження. Перелічіть файли unit знову після завершення перезавантаження й переконайтеся, що назва більше не зявляється.

Знайдіть двійковий файл, який тримає цю схему живою

Увімкнений unit продовжує запускати демон, хоч би що думала база пакетів. Цей процес може повернути тунель, знову додати маршрути або відновити правило kill-switch, і поведінка виглядає надприродною, доки ви не оглянете схему. Ідіть шляхом ExecStart і перевірте, чи двійковий файл ще там, бо виконуваний файл, залишений у /opt, це все, що схемі потрібно. Видалення unit зупиняє запланований запуск; воно не видаляє програму.

Ставтеся до каталогів стану з такою ж обережністю. Токени облікових записів, згенеровані профілі та кешовані списки серверів живуть у /var/lib або в домашньому каталозі, і це облікові дані, а не сміттєвий кеш. Видаліть їх після зупинки служби, свідомо, і запишіть, що взяли.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Виберіть одного власника завантаження й перевірте його

Три кандидати можуть претендувати на завантаження, і встановлення всіх трьох дає гонку, а не подвійний захист. Файл автозапуску робочого столу працює лише після чийогось входу, unit systemd працює раніше, але потребує клієнта, що працює без екрана, а запис cron @reboot спрацьовує за розкладом, який може бути неправильним для мережевого клієнта. CLI постачальника може додатково вимагати аргумент сервера, бо під час завантаження немає попередньої сесії для продовження. Виберіть кандидата, що відповідає способу автентифікації клієнта, і відкиньте інших.

Перевірте це, перезавантаживши машину й подивившись на три незалежні факти: стан unit, список процесів і нове зєднання з чимось, що можна перевірити. Клієнт, якому потрібен звязок ключів або інтерактивний вхід, зазнає невдачі під час завантаження навіть із правильним файлом unit, і journal говорить про це, якщо читати його, а не лише статус служби.

Або дайте клієнту облікові дані, що працюють без запиту, або запускайте його під час входу. Обидва варіанти захищені, а їх поєднання це спосіб, у який один тунель отримує двох власників, які за нього сваряться.

Запишіть, чого має чекати наступний purge

Занотуйте два факти після будь-якого ручного видалення: який інсталятор створив схему і який власник тепер її запускає. Ця нотатка перетворює наступний purge з несподіванки на пункт контрольного списку, і вона живе довше за людину, яка виконала роботу.

Тримайте її поруч із конфігурацією служби, а не в особистому каталозі, і ставте дату, бо оновлення постачальника може відновити видалений unit. Порівняння systemctl list-unit-files із цією нотаткою раз на кілька місяців ловить відновлення, поки виправлення ще дешеве.