Ubuntu 24.04: «dpkg was interrupted» — безпечна послідовність відновлення (без рулетки)

Це повідомлення зазвичай з’являється в найневдаліший момент. Ви намагаєтеся пропатчити сервер, встановити драйвер або підключити бібліотеку для деплою — і Ubuntu відповідає:
“dpkg was interrupted, you must manually run ‘dpkg –configure -a’”.

Можна діяти грубо. Люди так роблять. І іноді «працює», як витягування USB-накопичувача «працює», поки одного разу не перестає. Ось безпечна послідовність відновлення для Ubuntu 24.04:
вона завершує очікувані дії, виправляє пошкоджені частини та пояснює, чому це сталося — без перетворення бази пакетів на місце злочину.

Що насправді означає помилка (і чого вона не означає)

Стек пакетного керування в Ubuntu — це по суті багаторівнева система:
APT (apt/apt-get) — це високорівневий розв’язувач залежностей і завантажувач, а
dpkg — низькорівневий інсталятор, який розпаковує файли, запускає maintainer-скрипти та оновлює базу статусів пакетів.
Коли dpkg переривається — відключення живлення, процес був вбитий, диск заповнений, конфлікт блокувань або помилка скрипта — APT не може безпечно продовжити, поки стан dpkg не повернуть у консистентну точку.

Страшне в тому, що «перервано» не завжди означає «завалився». Часто це означає «ще одна операція з пакетами зараз виконується» або «попередня операція залишила пакети в напівсконфігурованому стані». Ця різниця важлива, бо фікс буде різним. Безпечний шлях починається з спостереження, а не хаотичного натискання кнопок.

Ось ментальна модель, яка збереже вас від проблем:

• База даних dpkg авторитетна: /var/lib/dpkg/status плюс допоміжні файли під /var/lib/dpkg/.
• “Configured” — це рубіж: розпакованих файлів недостатньо; maintainer-скрипти мають завершитися успішно.
• Блокування — це захист: вони не дають двом інсталятору одночасно редагувати базу.
• Більшість випадків «dpkg was interrupted» відновлювані: якщо ви не почнете видаляти випадкові файли в /var/lib/dpkg/.

Цитата, яка має бути в кожному runbook для чергових:
Hope is not a strategy. — General Gordon R. Sullivan

Швидкий план діагностики

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

1) Чи змагаєтеся ви з іншим процесом пакетного менеджера?

Найпоширеніша причина — і найнудніша: інша інстанція apt/dpkg працює (часто unattended-upgrades).
Якщо ви вб’єте її наосліп, ви можете знову перервати dpkg і погіршити стан.

2) Чи застряг dpkg на maintainer-скрипті або чекає вводу?

dpkg може виглядати «перерваним», коли postinst-скрипт завис (чекає на мережу, перезапуск сервісу зайшов у дедлок, зламаний DNS),
або коли потрібне рішення щодо конфігурації, а ви не підключені до терміналу.

3) Чи є проблеми з диском, inode або файловою системою?

Низьке місце на / або /var може спричинити напівзаписані файли статусу і провали на стадіях розпаковування/конфігурації.
На системах із окремими /var або маленькими кореневими розділами це класика.

4) Тільки після цього: запускайте кроки відновлення dpkg

Безпечна послідовність починається з завершення очікуваних конфігурацій, потім виправлення залежностей, потім повторного запуску перерваних тригерів.
Якщо ви одразу переходите до «видалити файли блокувань» або «rm -rf /var/lib/dpkg/info», ви граєте в рулетку з пакетним менеджером.

Цікаві факти та історія (коротко, корисно, і трохи нудно)

1. dpkg передував apt: dpkg з’явився в середині 1990-х як інструмент Debian; apt прийшов пізніше як розв’язувач залежностей поверх нього.
2. Блокування навмисно прості: dpkg використовує файлові блокування, щоб навіть мінімальне середовище відновлення могло зрозуміти стан пакетів.
3. Maintainer-скрипти — це реальні програми: postinst/prerm-скрипти можуть робити майже все — перезапускати сервіси, створювати користувачів, мігрувати дані — тож «встановлення пакета» фактично є керованим автоматизаційним виконанням.
4. Тригери скоротили дублюючу роботу: dpkg triggers (наприклад оновлення кешу іконок або man-db) додані, щоб багато пакетів не виконували однакові дорогі операції повторно.
5. Unattended upgrades змінили поле помилок: коли сервери почали автоматично застосовувати патчі без участі людини, конфлікти блокувань стали топ-причиною помилок dpkg для людей.
6. База статусу dpkg — це текст: /var/lib/dpkg/status можна читати пейджером і в екстрених випадках її можна відновити — обережно — бо це не бінарний файл.
7. dpkg має «напіввстановлені» стани за дизайном: переходи станів пакетів записуються, щоб dpkg міг продовжити, а не ігнорувати, що сталося.
8. «conffiles» — це особливі файли: dpkg ставиться до файлів конфігурації по-іншому, і перервані запити щодо конфігурацій часто пов’язані з конффайлами.

Безпечна послідовність відновлення (покроково, без рулетки)

Ось послідовність, яку я рекомендую на Ubuntu 24.04, коли ви бачите «dpkg was interrupted».
Вона безпечна, бо відповідає на три питання в порядку:
(1) Чи щось активно працює?
(2) Що зараз зламано?
(3) Яка мінімальна дія, щоб дійти до консистентного стану?

Крок 0: Отримайте root-shell і припиніть імпровізації

Використайте одну привілейовану сесію (sudo -i) і тримайте її відкритою. Не запускайте apt у п’яти терміналах одночасно.
Якщо ви на віддаленій системі, користуйтеся стійкою сесією (tmux/screen), щоб обрив SSH не став наступним «перериванням» для dpkg.

Крок 1: Перевірте, чи працюють менеджери пакетів і чи є блокування

Існують два види «заблоковано»:
реальний процес утримує блокування (добре), або існує застарілий файл блокування, бо процес помер у невдалий момент (менш поширено, але реально).
Ви діагностуєте це, перевіривши, хто володіє блокуванням.

Крок 2: Якщо щось працює — зачекайте, потім вирішіть, чи потрібно втручатися

Якщо unattended-upgrades виконує свою роботу, дайте йому завершити. Чекати п’ять хвилин — крихітна ціна порівняно з ризиком форсувати напівоновлення.
Якщо воно застрягло на годину і немає прогресу, можливо, треба втрутитися — але робіть це на основі доказів: логи, strace або стан сервісу.

Крок 3: Якщо нічого не працює — спочатку завершіть очікувані конфігурації

dpkg --configure -a не чарівна. Вона просто проходить по пакетах у «несконфігурованих» станах і запускає їхні скрипти конфігурації.
Якщо пакет напіввстановлений, конфігурація може впасти до появи залежностей — тому виправлення залежностей іде після цього, а не перед цим.

Крок 4: Виправте залежності за допомогою apt у режимі «fix broken»

Коли dpkg спробував налаштувати все, що може, запустіть виправлення залежностей через APT.
Саме тут APT може встановити відсутні залежності або підправити версії, щоб задовольнити обмеження.

Крок 5: Повторно запустіть configure, щоб завершити щойно розпаковані пакети

Виправлення залежностей часто розпаковує пакети, але залишає їх потребуючими конфігурації. Запустіть dpkg configure ще раз.
Так, це здається зайвим. Але саме так ви отримаєте консистентну систему, а не «майже нормальну».

Крок 6: Перевірте здоров’я dpkg/apt і приберіть залишки

Підтвердьте, що пакети не залишилися в напіввстановленому або несконфігурованому стані, і що APT може виконувати нормальні операції.
Лише після цього продовжуйте з тим встановленням/оновленням, яке планували спочатку.

Жарт №1: Видалення файлів блокувань, щоб «виправити» dpkg, схоже на вимикання датчика диму, щоб «виправити» писк. Ставало тихіше — аж до початку цікавої частини.

Практичні завдання: команди, виводи, рішення (12+)

Ось реальні завдання, які ви можете виконати негайно. Кожне містить команду, що зазвичай означає її вивід, і рішення, яке треба прийняти далі.
Припускаю, що ви на Ubuntu 24.04 і маєте sudo.

Завдання 1: Підтвердьте ОС і контекст (не припускайте)

cr0x@server:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.1 LTS
Release:        24.04
Codename:       noble

Значення: Ви дійсно на 24.04 (Noble). Деякі поведінки пакетування відрізняються між релізами.
Рішення: Продовжуйте за цими кроками; якщо ви в контейнері або похідній ОС, скоригуйте очікування (systemctl може працювати не як звично).

Завдання 2: Перевірте, чи dpkg/apt зараз працює

cr0x@server:~$ ps aux | egrep -i 'apt|dpkg|unattended|packagekit' | grep -v egrep
root         812  0.0  0.2  18332  9780 ?        Ss   10:11   0:00 /usr/bin/unattended-upgrade-shutdown --wait-for-signal
root         925  0.2  1.1 115184 46392 ?        S    10:12   0:01 /usr/bin/python3 /usr/bin/unattended-upgrade
root        1044  0.0  0.1  10420  5364 ?        Ss   10:12   0:00 /usr/bin/dpkg --status-fd 39 --configure --pending

Значення: dpkg активно конфігурує пакети під контролем unattended-upgrades.
Рішення: Чекайте. Не запускайте apt паралельно. Якщо потрібно втрутитися — зафіксуйте логи спочатку (див. наступні завдання).

Завдання 3: Визначте, хто тримає блокування (і чи воно реальне)

cr0x@server:~$ sudo fuser -v /var/lib/dpkg/lock-frontend
                     USER        PID ACCESS COMMAND
/var/lib/dpkg/lock-frontend:
                     root       1044 F....  dpkg

Значення: PID 1044 (dpkg) легітимно тримає блокування.
Рішення: Дайте йому завершити або діагностуйте цей процес (Завдання 6/7). Не видаляйте файли блокувань.

Завдання 4: Якщо є блокування, перевірте, чи процес його тримає

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dpkg    1044 root    3uW  REG  252,0        0  945 /var/lib/dpkg/lock-frontend

Значення: Файл блокування відкритий dpkg.
Рішення: Те саме, що вище: почекайте або відлагоджуйте dpkg; не «видаляйте блокування».

Завдання 5: Якщо ніхто не тримає блокування, підтвердьте, що воно застаріле (обережно)

cr0x@server:~$ sudo fuser -v /var/lib/dpkg/lock-frontend
cr0x@server:~$ echo $?
1

Значення: Ніякий процес не використовує цей файл. Код виходу 1 типово означає «немає користувачів».
Рішення: Тепер можна розглянути очищення застарілого блокування — але тільки після підтвердження відсутності процесів apt/dpkg (Завдання 2) і наявності логів, щоб зрозуміти останню помилку.

Завдання 6: Спостерігайте за прогресом dpkg у логах

cr0x@server:~$ sudo tail -n 80 /var/log/dpkg.log
2025-12-28 10:12:18 configure linux-image-6.8.0-41-generic:amd64 6.8.0-41.41
2025-12-28 10:12:19 status unpacked linux-modules-6.8.0-41-generic:amd64 6.8.0-41.41
2025-12-28 10:12:24 configure openssh-server:amd64 1:9.6p1-3ubuntu13.5
2025-12-28 10:12:25 trigproc man-db:amd64 2.12.0-4build2 <none>

Значення: dpkg рухається через configure і обробку тригерів. Якщо мітки часу оновлюються — процес живий.
Рішення: Чекайте. Якщо мітки часу довго стоять на конкретному пакеті — дослідіть скрипти того пакета (Завдання 12).

Завдання 7: Перевірте journald на предмет збоїв перезапуску сервісів apt/dpkg

cr0x@server:~$ sudo journalctl -b -u unattended-upgrades --no-pager -n 60
Dec 28 10:12:08 server unattended-upgrades[925]: Installing the upgrades failed!
Dec 28 10:12:08 server unattended-upgrades[925]: error: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Dec 28 10:12:08 server unattended-upgrades[925]: Traceback (most recent call last):
Dec 28 10:12:08 server unattended-upgrades[925]:   ...

Значення: unattended-upgrades натрапив на переривання dpkg і припинив роботу. Це не означає, що dpkg все ще працює.
Рішення: Якщо процес dpkg відсутній, переходьте до ручного відновлення (Завдання 9 і далі).

Завдання 8: Підтвердьте наявність місця та інодів (класичний тихий вбивця)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        30G   29G  420M  99% /

Значення: Ви на 99% кореневого розділу. dpkg пише в /var/lib/dpkg і розпаковує в /; це цілком може спричинити відмову посеред транзакції.
Рішення: Звільніть місце до відновлення. Очистіть кеш пакетів, логи або старі ядра (Завдання 8b/8c).

cr0x@server:~$ df -i /
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda2      1966080 1891120  74960   97% /

Значення: Inode-ів теж майже не лишилося. Багато дрібних файлів можуть зламати стадії розпаковування/конфігурації.
Рішення: Знайдіть споживачів inode (наприклад, лог-шторм, директорії кешу) перед тим як повторювати dpkg.

Завдання 9: «Сухий» запуск відновлення: подивіться, що dpkg вважає очікуваним

cr0x@server:~$ sudo dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 linux-image-6.8.0-41-generic  Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Значення: dpkg має конкретний пакет у стані «напівсконфігурований».
Рішення: Можна виконати глобальну конфігурацію (dpkg --configure -a) або націлитися на цей пакет. Починайте з глобальної, якщо ви не дебагуєте відомого винуватця.

Завдання 10: Запустіть канонічний крок відновлення dpkg (із видимістю)

cr0x@server:~$ sudo dpkg --configure -a
Setting up linux-image-6.8.0-41-generic (6.8.0-41.41) ...
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic
Setting up openssh-server (1:9.6p1-3ubuntu13.5) ...
Processing triggers for man-db (2.12.0-4build2) ...

Значення: dpkg конфігурує очікувані пакети і запускає тригери. Якщо воно завершується без помилок — зазвичай ви закінчили.
Рішення: Якщо з’являється помилка — зафіксуйте конкретний пакет і повідомлення, потім використайте apt fix-broken (Завдання 11) або відлагоджуйте скрипт (Завдання 12/13).

Завдання 11: Виправте залежності (безпечний хід apt)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  linux-modules-6.8.0-41-generic
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.
Need to get 32.1 MB of archives.
After this operation, 137 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y

Значення: APT знайшов відсутні залежності і пропонує конкретний план виправлення.
Рішення: Якщо план виглядає адекватно — підтвердіть. Якщо він хоче видалити критичні пакети — зупиніться і перевірте pinning/утримані пакети (Завдання 14/15).

Завдання 12: Якщо maintainer-скрипт падає, запускайте його з ментальністю трасування (не вгадуйте)

cr0x@server:~$ sudo dpkg --configure linux-image-6.8.0-41-generic
Setting up linux-image-6.8.0-41-generic (6.8.0-41.41) ...
run-parts: failed to exec /etc/kernel/postinst.d/zz-update-grub: No such file or directory
dpkg: error processing package linux-image-6.8.0-41-generic (--configure):
 installed linux-image-6.8.0-41-generic package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 linux-image-6.8.0-41-generic

Значення: Пост-інсталяційний скрипт ядра очікував хук, якого не існує. Це реальна помилка, а не «dpkg просто шумить».
Рішення: Визначте, який пакет забезпечував цей скрипт (зазвичай grub-пов’язаний), перевстановіть/виправте його, потім знову запустіть dpkg configure.

Завдання 13: Знайдіть, який пакет володіє відсутнім файлом (швидка перевірка власності)

cr0x@server:~$ dpkg -S /etc/kernel/postinst.d/zz-update-grub
dpkg-query: no path found matching pattern /etc/kernel/postinst.d/zz-update-grub

Значення: Жоден встановлений пакет наразі не володіє цим файлом. Або його видалили, або відсутній пакет, який мав би його надати.
Рішення: Перевстановіть ймовірного провайдера (зазвичай grub2-common) або відновіть директорію хуків з бекапів/системи керування конфігурацією.

Завдання 14: Перевірте утримані пакети (APT може відмовити тихо)

cr0x@server:~$ apt-mark showhold
linux-image-generic

Значення: Щось утримується на hold. Це може перешкоджати виправленню залежностей ядра і зациклити dpkg.
Рішення: Якщо hold зроблено навмисно (наприклад для відповідності) — сплануйте контрольоване оновлення ядра. Якщо це випадковість — зніміть hold і повторіть fix-broken.

Завдання 15: Перегляньте стан dpkg на предмет «напіввстановлених» або «розпакованих» пакетів

cr0x@server:~$ dpkg -l | awk '$1 ~ /^(iF|iU|iH|rc|un|pn)$/ {print}'
iF  linux-image-6.8.0-41-generic  6.8.0-41.41  amd64  Linux kernel image for version 6.8.0 on 64 bit x86 SMP

Значення: iF вказує на «installed, failed-config». Ось ваш найяскравіший маркер.
Рішення: Виправте конфігурацію цього пакета або його залежності; не продовжуйте пробувати випадкове встановлення, поки він битий.

Завдання 16: Перевірте, чи apt знає про зламані пакети

cr0x@server:~$ sudo apt-get check
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 linux-image-6.8.0-41-generic : Depends: linux-modules-6.8.0-41-generic but it is not installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

Значення: APT підтверджує проблеми з залежностями.
Рішення: Використайте apt-get -f install (Завдання 11), а не ручні dpkg-встановлення, якщо ви не виконуєте офлайн-відновлення.

Завдання 17: Очистьте кеш APT, якщо диск тісний (безпечне, оборотне)

cr0x@server:~$ sudo apt-get clean
cr0x@server:~$ sudo du -sh /var/cache/apt/archives
12K	/var/cache/apt/archives

Значення: Кеш очищено; ви звільнили місце (іноді гігабайти).
Рішення: Повторіть dpkg configure і apt fix-broken, якщо тиск по диску блокував вас.

Завдання 18: Якщо треба видалити застарілий файл блокування — робіть це лише після доведення його застарілості

cr0x@server:~$ sudo rm -v /var/lib/dpkg/lock-frontend
removed '/var/lib/dpkg/lock-frontend'

Значення: Ви видалили файл блокування. Це не рутинна операція; це останній крок після підтвердження, що ніхто не тримає файл.
Рішення: Негайно запустіть dpkg --configure -a, щоб узгодити стан, а потім виконайте apt check. Якщо ви помилилися, можете пошкодити базу dpkg.

Жарт №2: Якщо ваш «фікс» включає rm -f /var/lib/dpkg/*, вітаю — ви винайшли нову стратегію деплою під назвою «археологія».

Контрольні списки / покроковий план

Чекліст A: Безпечна послідовність відновлення (стандартний випадок)

1. Відкрийте стабільну адмінську сесію (tmux/screen, якщо віддалено).
2. Підтвердіть, що інші apt/dpkg не працюють:
   • ps aux | egrep -i 'apt|dpkg|unattended|packagekit'
   • fuser -v /var/lib/dpkg/lock-frontend
3. Перевірте запас місця та inode:
   • df -h /
   • df -i /
4. Аудит стану dpkg: dpkg --audit
5. Сконфігуруйте очікувані пакети: sudo dpkg --configure -a
6. Виправте залежності: sudo apt-get -f install
7. Повторіть конфігурацію: sudo dpkg --configure -a
8. Перевірте стан:
   • sudo apt-get check
   • dpkg -l | awk '$1 ~ /^(iF|iU|iH)$/ {print}'

Чекліст B: Коли процес тримає блокування

1. Визначте PID: fuser -v /var/lib/dpkg/lock-frontend
2. Подивіться, що він робить: ps -fp PID і tail -f /var/log/dpkg.log
3. Якщо є прогрес: чекайте.
4. Якщо завис:
   • Перевірте, чи чекає процес вводу (TTY) або завис під час перезапуску сервісу.
   • Перегляньте journald для відповідного сервісу пакета.
5. Якщо потрібно зупинити його: спробуйте спочатку зупинити високорівневий драйвер (unattended-upgrades), потім негайно знову запустіть dpkg configure.

Чекліст C: Коли диск або inode зайняті

1. Безпечно звільніть місце:
   • apt-get clean
   • Ротувати/стиснути логи, якщо політика це дозволяє.
   • Обережно видаляти старі ядра (уникайте видалення запущеного).
2. Потім запустіть:
   • dpkg --configure -a
   • apt-get -f install
   • apt-get check

Типові помилки: симптом → причина → виправлення

Це шаблони, які ви побачите в реальному операційному житті. Хитрість — трактувати симптоми як крихти, а не образу.

Помилка 1: «Could not get lock /var/lib/dpkg/lock-frontend»

• Симптом: apt каже, що не може отримати блокування.
• Причина: Інший процес apt/dpkg працює (часто unattended-upgrades або PackageKit), або існує застарілий файл блокування.
• Виправлення: Використайте fuser -v і lsof для підтвердження. Якщо процес тримає файл — чекайте. Якщо ніхто не тримає — видаліть застаріле блокування тільки після підтвердження, що apt/dpkg не працюють, потім запустіть dpkg --configure -a.

Помилка 2: Багаторазовий запуск apt, поки dpkg пошкоджений

• Симптом: Кожна команда apt завершується з «dpkg was interrupted» або «dpkg returned an error code (1).»
• Причина: dpkg має пакети в нестабільному стані (iF/iU), і APT відмовляється продовжувати.
• Виправлення: Запустіть dpkg --audit, потім dpkg --configure -a, потім apt-get -f install.

Помилка 3: Убити dpkg, бо «дуже довго виконується»

• Симптом: Після kill -9 ви отримуєте повторювані помилки конфігурації і більший безлад.
• Причина: dpkg був у середині транзакції або виконував тригери; ви знову його перервали.
• Виправлення: Якщо dpkg справді завис, діагностуйте точку зависання: підглядайте логи, перевірте конкретний maintainer-скрипт, перевірте диск і мережеві залежності. Уникайте SIGKILL, поки не готові до вікна відновлення.

Помилка 4: Видалення випадкових файлів під /var/lib/dpkg

• Симптом: dpkg повідомляє про відсутні info-файли, пакети «не встановлені», але файли все ще є, або невідповідності у статусі.
• Причина: Хтось намагався «скинути» dpkg, видаляючи метадані.
• Виправлення: Відновіть з бекапу, якщо можливо. Інакше обережно перевстановіть уражені пакети і відновіть стан вручну. Очікуйте ручної роботи. Найбезпечніший запобіжник — не робити цього спочатку.

Помилка 5: Ігнорування запитів щодо conffile у безінтерактивних середовищах

• Симптом: dpkg здається завислим; процесор майже не використовуєся; логи dpkg не рухаються.
• Причина: dpkg чекає запиту щодо файлу конфігурації, але немає доступного фронтенду (наприклад, в автоматизації не встановлено DEBIAN_FRONTEND відповідно).
• Виправлення: Запустіть інтерактивно або встановіть політику для conffiles і виконуйте оновлення з noninteractive опціями в автоматизації. Потім знову запустіть dpkg --configure -a.

Помилка 6: APT пропонує видалити «важливі» пакети для виправлення залежностей

• Симптом: apt-get -f install пропонує видалити базові пакети (мета-пакети ядра, ssh, компоненти systemd).
• Причина: Змішані репозиторії, зафіксовані версії, часткове оновлення або утримані пакети перешкоджають знайти консистентне рішення.
• Виправлення: Перевірте утримання (apt-mark showhold), політику (apt-cache policy package), і знайдіть змішання репозиторіїв. Не погоджуйтеся на масові видалення на сервері, який вам важливий.

Три історії з корпоративного досвіду

Інцидент через неправильне припущення: «Це просто застаріле блокування»

Середня компанія експлуатувала флот серверів Ubuntu для внутрішніх сервісів. Інженер побачив повідомлення про переривання dpkg під час пізнього вікна патчів.
Вони вже бачили проблеми з блокуваннями раніше і припустили, що це те саме: видалити файл блокування, повторно запустити apt і додому.

Блокування не було застарілим. Unattended upgrade активно переконфігурував libc та суміжні пакети. Інженер видалив файл блокування і запустив паралельний apt.
Тепер два процеси писали в базу dpkg, і файл статусу став неконсистентним. Наступний ребут не впав феєрично; він впав тихо — сервіси не піднялися, бо кілька пакетів були в «напівналаштованих» станах і деякі postinst-скрипти ніколи не завершилися.

Вони провели наступний ранок, виконуючи незручні дії: перевіряли стани dpkg, перевстановлювали пакети і розплутували ланцюги залежностей. Найгірше було не технічне виправлення.
Найгірше — невизначеність: кожен крок відновлення міг погіршити ситуацію, і команда не знала, в якому стані насправді має бути машина.

Висновок не в «ніколи не видаляти файли блокувань». Висновок: ставтеся до блокувань як до симптома, а не діагнозу.
Якщо процес тримає блокування — видаляти його означає саботаж, замаскований під рішучість. Доведіть, що воно застаріле, перед дією.

Оптимізація, що обернулася проти: «Прискоримо оновлення, примусово вимкнувши запити»

Інша організація мала ідею: оновлення ніколи не має питати, бо запити гальмують автоматизацію. Вони встановили агресивні значення середовища:
DEBIAN_FRONTEND=noninteractive, плюс опції для автоматичного прийняття змін у конффайлах. Це розгорнули по серверах.

Це працювало красиво, поки не перестало. Критичне оновлення сервісного пакета внесло зміну в conffile, де «нова» конфігурація видаляла застарілий include-шлях.
На серверах з кастомізаціями автоматичний вибір конффайла фактично перезаписав локальні налаштування. dpkg завершився швидко — місія виконана, так?

Потім почалися вторинні відмови: сервіси перезапустилися як частина postinst, підхопили нову конфігурацію, і деякі екземпляри провалили перевірки здоров’я.
Пайплайн деплою звинуватив додаток. SRE на чергуванні звинуватив мережу. Ніхто не дивився dpkg-логи годину, бо «пакети встановилися».

Коли вони все простежили, виправлення було простим: відновити очікуваний стан управління конфігурацією і задати політику для конкретних пакетів щодо conffile.
Складніше було змінити культуру: швидкість — не єдиний KPI; детермінованість оновлень важливіша.
Політика автоматизації для dpkg потребує обмежень, а не загального «ніколи не питаємо» підходу.

Нудна, але правильна практика, що врятувала день: «Одна стійка сесія, одне оновлення за раз»

Фінансова команда мала регульовані навантаження, де патчі мають бути швидкими і аудитується.
Їхній runbook був нудним: оновлення лише з постійної сесії, відключати паралельні операції пакетів, робити снапшот перед ризиковими оновленнями і логувати кожну дію в тікеті.
Інженери жартували, що це «паперова робота з sudo».

Під час рутинного оновлення maintainer-скрипт завис, бо перезапуск сервісу чекав на залежність, тимчасово недоступну в мережі (хибка внутрішнього mirror).
dpkg не впав; він чекав. Черговий дотримався runbook: тримати сесію, дивитися логи dpkg, підтвердити, що процес ще працює, і перевірити диск.

Коли стало ясно, що блокування пов’язане з мережею, вони відновили доступ до mirror і dpkg продовжив роботу.
Ніякого видалення блокувань. Ніякого вбивства dpkg. Ніяких часткових оновлень у різних терміналах. Тільки методичні перевірки.

Висновок: цей runbook запобіг набагато гіршому інциденту, бо зберіг здатність dpkg завершити станову машину коректно.
Нудне — не протилежність розумного. Це протилежність хаосу.

Питання та відповіді

1) Чи завжди запускати dpkg --configure -a?

Якщо ви бачите «dpkg was interrupted», так — після того як підтверджено, що інші процеси пакетного менеджера не працюють і немає проблем із диском.
Запуск у той час, коли інший dpkg тримає блокування, просто створить більше шуму.

2) Чи безпечно видаляти /var/lib/dpkg/lock-frontend?

Лише коли ви довели, що файл застарілий: немає процесів apt/dpkg/unattended-upgrades, і fuser/lsof показують, що ніхто не тримає файл.
Якщо процес тримає блокування — видаляти файл — невірний «фікс».

3) Чому apt постійно радить запускати dpkg вручну?

Бо dpkg володіє низькорівневим станом. APT не стане пробувати складні операції з залежностями, якщо база dpkg вказує на незавершені переходи.
Це функція безпеки, а не персональна образа.

4) Що робити, якщо dpkg завис і не виводить нічого?

Перегляньте /var/log/dpkg.log для останнього пакета, якого торкнувся процес. Далі підозрюйте: запит щодо conffile, завислий postinst-скрипт, перезапуск сервісу в очікуванні або ресурсний дефіцит.
journald-логи часто показують, який сервіс не зміг перезапуститися.

5) Чи можна перезавантажити сервер, щоб виправити це?

Ребут може прибрати завислий процес, але це не «полагодить» стан dpkg. Після ребуту вам зазвичай все одно треба виконати
dpkg --configure -a і можливо apt-get -f install.
Ребут прийнятний, якщо ви не можете безпечно зупинити завислий dpkg і маєте вікно обслуговування.

6) Що означає iF у dpkg -l?

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

7) Чому пакети ядра часто з’являються в таких інцидентах?

Оновлення ядра включає генерацію initramfs, хуки завантажувача і тригери. Це більше рухомих частин, ніж оновлення невеликої бібліотеки.
Місце у /boot або відсутні grub-хуки можуть перетворити звичайне оновлення в помилку dpkg.

8) Чи відрізняється apt --fix-broken install від apt-get -f install?

За суттю вони прагнуть одного: виправити зламані залежності. Формат виводу відрізняється, а apt-get стабільніший для скриптів.
У сценарії відновлення я віддаю перевагу apt-get -f install, бо він передбачуваний.

9) Що робити, якщо сама база статусу dpkg пошкоджена?

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

10) Як запобігти повторенню цього?

Не запускайте apt паралельно, тримайте запас місця на диску, моніторте unattended-upgrades і використовуйте стійкі сесії для оновлень.
Більшість переривань dpkg — це питання операційної гігієни, а не екзотичні баги.

Висновок: наступні кроки, які ви справді виконаєте

Безпечна послідовність відновлення не складна. Вона дисциплінована:
доведіть, чи працює пакетний менеджер, перевірте ресурси, завершіть очікувані конфігурації, виправте залежності і валідуйте стан.
Ось і все. Різниця між чистим відновленням і втраченим днем — у тому, чи ставите вися dpkg як базу даних, чи як автомат порядкових чисел.

Наступні кроки:

1. Виконайте швидкий план діагностики в порядку: процес/блокування → завислий скрипт → диск/inode → dpkg configure.
2. Виконайте стандартний чекліст відновлення (configure, fix-broken, configure знову).
3. Підтвердьте здоров’я за допомогою dpkg --audit і apt-get check перед тим як робити первинне встановлення/оновлення.
4. Запишіть, що спричинило переривання — тиск диска, unattended upgrades, збій postinst — щоб не зустріти це знову наступного тижня.