Debian 13: core-дампи заповнюють диск — збережіть відладну цінність, позбудьтеся зайвого

October 7, 2025 • February 3, 2026 • Читання: 5 хв • Views: 7

Було корисно?

Ви не собі придумали: один збій може розгорнути core-дамп розміром з вашу ОЗП на диск, і Debian 13 охоче продовжить це робити, поки вузол не почне
давати помилки записи, база даних не перейде в режим тільки для читання, а «невелика проблема в додатку» не перетвориться на інцидент платформи.

Виправлення — не «відключити дампи всюди» (саме так ви опинитеся відлагоджувати навмання). Потрібна політика: зберігати тільки потрібні дампи, зберігати їх
коротко, стискати, коли це недорого, і змусити систему зупинитися, перш ніж вона з’їсть машину.

Що насправді відбувається, коли диск заповнюється core-дампами

Core-дамп — це знімок пам’яті процесу у момент його загибелі (зазвичай через фатальний сигнал). Він корисний, бо містить стан, який пізніше неможливо
відновити: кадри стеку, об’єкти кучи, стани потоків і іноді чутливі дані, які краще не зберігати місяцями.

У сучасному Debian обробка дампів зазвичай проходить через systemd-coredump. Ядро бачить процес, що впав, дивиться
/proc/sys/kernel/core_pattern і або записує файл напряму, або передає дамп у обробник. З systemd цей обробник може зберігати дамп у
/var/lib/systemd/coredump/ і логувати метадані в журнал.

Режим відмови «диск заповнений» має кілька типових форм:

Цикли частих падінь: сервіс перезапускається, негайно падає, повторюється. Кожен збій генерує новий дамп.
Великі процеси: JVM, браузери, рантайми мов або будь-що з великою кучею. Один дамп може сягати десятків гігабайт.
Неправильне розміщення: дампи потрапляють у /var, який у вас на найменшому розділі (бо хтось лишив налаштування з 2009 року).
Відсутність ретеншну: ви припустили, що «systemd очистить». Він так і зробить, але тільки якщо сконфігурований і тільки за своїм графіком.
Безпека та приватність: хтось вимикає дампи глобально, щоб уникнути витоку секретів, і ви втрачаєте єдиний судовий артефакт.

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

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

План швидкої діагностики (перший / другий / третій)

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

Перший: підтвердіть, яка файловa система заповнена і що росте

Визначте повний точний mount point і пристрій, що за ним стоїть.
Підтвердіть, чи це /var, / чи окремий том.
Знайдіть головних винуватців по розміру директорій, а не за припущеннями.

Другий: підтвердіть, що це core-дампи, і знайдіть джерело збою

Перевірте розмір і часові мітки в /var/lib/systemd/coredump.
Використовуйте coredumpctl, щоб знайти, який виконуваний файл падає і як часто.
Підтвердіть, чи це цикл перезапуску (flapping юніта systemd), чи одиничні відмови.

Третій: застосуйте відновлювальний крок, що можна відмінити, потім реалізуйте політику

Короткостроково: обмежте дампи, тимчасово вимкніть для конкретного сервісу або перемістіть місце зберігання.
Збережіть один-два репрезентативні дампи для відладки; очистіть решту після отримання доказів.
Потім: налаштуйте ретеншн (systemd-coredump), ліміти розміру та розміщення сховища.

Жарт №1 (короткий і по темі): Core-дампи як офісні закуски — без нагляду вони розростаються, щоб заповнити весь простір, і все одно залишають вас голодними.

Цікаві факти та коротка історія (бо у цього безладу є походження)

Невеликий контекст допомагає приймати кращі рішення. Ось конкретні факти, що мають значення операційно:

Core-дампи старші за Linux: Unix-системи зливали пам’ять процесів ще з 1970-х; ідея старша за більшість runbook-ів.
«core» — не метафора: ранні машини використовували магнетне core-пам’ять; «core dump» буквально означав дамп вмісту core-пам’яті.
За замовчуванням місця зберігання змінювалися: старі налаштування писали ./core в поточний робочий каталог; сучасні дистрибутиви часто маршрутизують через системні сервіси.
Ядро вирішує, чи дозволено дампувати: setuid бінарники та привілейовані контексти можуть бути обмежені з міркувань безпеки.
Розмір дампу — не просто «використана ОЗП»: мапінги пам’яті, huge pages та поведінка рантайму можуть зробити дамп більшим або меншим, ніж очікувалося.
Стиск — не безкоштовний: стиснення багатогігабайтних дампів забирає CPU і може відбирати цикли від відновлення й роботи з пам’яттю.
Метадані живуть окремо: з systemd ви отримаєте записи в журналі про дамп, навіть якщо файл дампу відсутній або пізніше видалений.
Дамп можна передати в пайп: core_pattern може передавати дамп обробнику; саме тому в патерні ви побачите ведучий |.

Практичні завдання: команди, що означає вивід, і рішення, які ви приймаєте

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

Завдання 1: Підтвердьте, які файлові системи заповнені

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4    40G   39G  320M  99% /
/dev/sda3      ext4    20G   19G  400M  98% /var
tmpfs          tmpfs  3.1G   12M  3.1G   1% /run

Значення: Гинуть / і /var, а не якийсь довільний дата-том. Це вказує прямо на логи, кеші пакетів, спули й, так, core-дампи.

Рішення: Сфокусуйтеся на /var і припиніть запис туди. Якщо /var — окрема ФС, часто легше відновитися, чистячи тільки /var, не дестабілізуючи всю ОС.

Завдання 2: Знайдіть топ-директорії під /var за реальним розміром

cr0x@server:~$ sudo du -xhd1 /var | sort -h
24M     /var/cache
180M    /var/log
1.1G    /var/tmp
17G     /var/lib
19G     /var

Значення: /var/lib — важковаговик. Це узгоджується зі зберіганням systemd-coredump.

Рішення: Розгорніть аналіз у /var/lib перед тим, як чіпати логи або кеші. Інцидент швидше вирішиться, коли ви видалите правильну річ одразу.

Завдання 3: Перевірте, чи systemd зберігає core-дампи на диск

cr0x@server:~$ sudo du -sh /var/lib/systemd/coredump
14G     /var/lib/systemd/coredump

Значення: Підтверджено: дампи присутні й великі.

Рішення: Не видаляйте все одразу. Спочатку ідентифікуйте програму, що падає, і збережіть принаймні один репрезентативний дамп.

Завдання 4: Перелічіть останні дампи і знайдіть винуватця

cr0x@server:~$ sudo coredumpctl list --no-pager | head
TIME                          PID  UID  GID SIG COREFILE  EXE
Mon 2025-12-29 10:02:41 UTC  9142  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:02:12 UTC  9136  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:01:43 UTC  9129  998  998  11 present   /usr/bin/myservice

Значення: Один бінар повторно дампить. Сигнал 11 — це segfault, класичний цикл падінь.

Рішення: Візьміть під контроль цикл падінь. Збережіть останній дамп, потім зупиніть накопичення нових дампів.

Завдання 5: Перевірте, чи це перезапусковий цикл systemd

cr0x@server:~$ systemctl status myservice.service --no-pager
● myservice.service - Example Service
     Loaded: loaded (/etc/systemd/system/myservice.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: core-dump) since Mon 2025-12-29 10:02:42 UTC; 1s ago
    Process: 9142 ExecStart=/usr/bin/myservice (code=dumped, signal=SEGV)
   Main PID: 9142 (code=dumped, signal=SEGV)

Значення: systemd робить саме те, що ви попросили: перезапускає сервіс і збирає дампи. Це також з’їдає ваш диск.

Рішення: Зупиніть юніт (або змініть політику перезапуску), щоб зупинити кровотечу, потім збережіть артефакти для відладки.

Завдання 6: Зупиніть сервіс, щоб запобігти новим дампам (триаж)

cr0x@server:~$ sudo systemctl stop myservice.service
cr0x@server:~$ sudo systemctl is-active myservice.service
inactive

Значення: Цикл падінь зупинився, принаймні на цьому вузлі. Зайнятість диска має припинити зростати.

Рішення: Якщо це сервіс флоту, подумайте про перемикання трафіку або вивантаження цього вузла. Стабілізуйтеся спочатку; відлагоджуйте потім.

Завдання 7: Ідентифікуйте найбільші файли дампів

cr0x@server:~$ sudo ls -lhS /var/lib/systemd/coredump | head
-rw------- 1 root root 6.8G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst
-rw------- 1 root root 6.7G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9136.1735466532000000.zst
-rw------- 1 root root 6.7G Dec 29 10:01 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9129.1735466503000000.zst

Значення: Дампи вже стиснуті (помітно за .zst), але все ще величезні. Це вказує, що образ пам’яті процесу великий.

Рішення: Збережіть один дамп (зазвичай найновіший) для аналізу. Плануйте видалити старі дублікати після отримання backtrace.

Завдання 8: Витягніть деталі дампу без його копіювання

cr0x@server:~$ sudo coredumpctl info 9142
           PID: 9142 (myservice)
           UID: 998 (myservice)
           GID: 998 (myservice)
        Signal: 11 (SEGV)
     Timestamp: Mon 2025-12-29 10:02:41 UTC
  Command Line: /usr/bin/myservice --config /etc/myservice/config.yaml
    Executable: /usr/bin/myservice
 Control Group: /system.slice/myservice.service
          Unit: myservice.service
       Storage: /var/lib/systemd/coredump/core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst (present)

Значення: У вас є точне відображення інциденту на артефакт: юніт, командний рядок і шлях зберігання.

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

Завдання 9: Отримайте стек трасу (потрібні debug-символи, щоб бути дійсно корисними)

cr0x@server:~$ sudo coredumpctl gdb 9142 -q --batch -ex "thread apply all bt"
[New LWP 9142]
Core was generated by `/usr/bin/myservice --config /etc/myservice/config.yaml'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2f1a2b9c2a in memcpy () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000055b8f2b1a2f0 in parse_packet (ctx=0x55b8f3c12000) at src/net/parse.c:217
#2  0x000055b8f2b19d71 in worker_loop () at src/worker.c:88
#3  0x00007f2f1a1691f5 in start_thread () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f2f1a1e8b00 in clone () from /lib/x86_64-linux-gnu/libc.so.6

Значення: У вас є backtrace і файл/рядок, тож, ймовірно, вам не потрібні ще 20 однакових дампів.

Рішення: Залиште найновіший дамп і трасу. Видаліть решту, щоб відновити місце на диску. Якщо не вдається отримати символи, збережіть один дамп і зосередьтеся на зборі символів далі.

Завдання 10: Перевірте поточну конфігурацію systemd-coredump

cr0x@server:~$ sudo systemd-analyze cat-config systemd/coredump.conf
# /etc/systemd/coredump.conf
[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=8G
ExternalSizeMax=8G
MaxUse=16G
KeepFree=2G

Значення: Ліміти є, але вони можуть бути занадто щедрими для вашого розміру /var (або для вашої частоти падінь).

Рішення: Затягніть MaxUse і підвищте KeepFree, або перемістіть сховище на виділену файлову систему.

Завдання 11: Перевірте, що ядро зробить з дампами (core_pattern)

cr0x@server:~$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

Значення: Дампи передаються в systemd-coredump, а не записуються ядром напряму у шлях файлу.

Рішення: Виправляйте ретеншн через конфіг systemd-coredump (не редагуйте патерн шляху в надії, що це спрацює).

Завдання 12: Перевірте глобальний ліміт розміру core для поточної оболонки

cr0x@server:~$ ulimit -c
unlimited

Значення: Принаймні в вашій оболонці ліміт розміру дампів не встановлений. Для сервісів ефективний ліміт може задаватися в налаштуваннях systemd unit.

Рішення: Встановлюйте ліміти в юніті (переважно) або через PAM limits для інтерактивних сесій, залежно від контексту.

Завдання 13: Перевірте ліміт core, застосований до запущеного процесу

cr0x@server:~$ pidof myservice
9210
cr0x@server:~$ grep -E '^Max core file size' /proc/9210/limits
Max core file size        unlimited            unlimited            bytes

Значення: Сервіс може генерувати дампи повного розміру.

Рішення: Якщо ви хочете «деякі» дампи, але не величезні, обмежте розмір так, щоб зберегти стеки (часто сотні МБ), не зберігаючи повні кучі.

Завдання 14: Перевірте, чи journald також під тиском

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.4G in the file system.

Значення: Журнали не є головним винуватцем тут, але 1.4G все одно може мати значення на крихітному /var.

Рішення: Не «вакуумуйте» журнал як перший крок, якщо дампи займають 14G. Виправте реальну проблему спочатку.

Завдання 15: Звільніть місце безпечно, видаливши старі дампи після збереження одного

cr0x@server:~$ sudo coredumpctl list --no-pager | awk '/myservice/ {print $5}' | head
present
present
present
cr0x@server:~$ sudo rm -f /var/lib/systemd/coredump/core.myservice.*.9136.*.zst /var/lib/systemd/coredump/core.myservice.*.9129.*.zst
cr0x@server:~$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        20G   12G  7.4G  62% /var

Значення: Ви відтермінували проблему і не стерли все сліпо.

Рішення: Тепер налаштуйте правильні ліміти, щоб цього не повторилося. Ручні видалення — для сьогодні, не для наступного тижня.

Розумна політика збереження для Debian 13 (зберігайте цінність, позбавляйтесь зайвого)

Ви хочете достатньо артефактів аварії, щоб відповісти: «що сталося?» Ви не хочете машини часу з усіма падіннями за останній квартал. Core-дампи —
артефакти з високим сигналом і високою вартістю зберігання.

Хороша політика має чотири частини:

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

Ось опінійована версія для більшості продакшн-флотів:

Увімкніть дампи для сервісів, де ви реально відлагоджуєте падіння (зазвичай так).
Обмежте пер-процесні дампи до розміру, що зберігає backtrace і стеки потоків (часто 256M–2G, залежно від мови/рантайму).
Тримайте максимум кілька гігабайт на вузол або на файлову систему дампів і забезпечте резерв вільного місця.
Краще зберігати дампи на виділеній файловій системі (або принаймні в директорії з передбачуваними квотами/лімітами).
Відправляйте метадані (не дампи) у централізоване місце. Переміщайте дампи за межі хоста лише коли вони дійсно потрібні.

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

Жарт №2 (другий і останній): Вимикати дампи всюди — це як знімати пожежні датчики, бо вони гучні — тихо, так; краще ситуація, ні.

systemd-coredump: конфігурація, що працює в продакшні

У Debian 13 systemd тут ваш союзник, але тільки якщо ви скажете йому, що означає «достатньо». Файл зазвичай:
/etc/systemd/coredump.conf (і drop-in-и під /etc/systemd/coredump.conf.d/).

Ключові опції, які важливо знати

Storage= Куди йдуть дампи: зовнішні файли, журнал, обидва варіанти або взагалі ні.
Compress= Чи стискувати core-файли (часто zstd). Корисно, але слід стежити за CPU під час штормів падінь.
ProcessSizeMax= Макс розмір процесного дампу, який підлягає обробці.
ExternalSizeMax= Макс розмір окремого зовнішнього файла дампу.
MaxUse= Максимальний простір на диску, який може займати systemd-coredump загалом.
KeepFree= Скільки вільного місця тримати на файловій системі, що містить дампи.

Практична базова конфігурація для вузла з /var 20–40G виглядає приблизно так:

MaxUse=2G — 6G залежно від того, наскільки ви цінуєте дампи порівняно з робочоздатністю.
KeepFree=2G — 5G щоб journald, оновлення пакетів і нормальна робота не вмерли.
ExternalSizeMax=512M — 2G щоб зберегти стек-трейси, не завжди зберігаючи багатогігабайтні купи.

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

Приклад: негайно звузити ретеншн (і безпечно)

cr0x@server:~$ sudo install -d /etc/systemd/coredump.conf.d
cr0x@server:~$ cat <<'EOF' | sudo tee /etc/systemd/coredump.conf.d/99-retention.conf
[Coredump]
Storage=external
Compress=yes
ExternalSizeMax=1G
MaxUse=4G
KeepFree=4G
EOF
cr0x@server:~$ sudo systemctl daemon-reload

Значення: Ви встановили жорсткі глобальні обмеження. Навіть якщо сервіс піде в рознос, вузол залишиться живим.

Рішення: Якщо регулярно потрібні повні купи для аналізу корупції пам’яті, підвищуйте ExternalSizeMax, але переміщуйте дампи з /var.
Не ілюзіюйте, що можете мати 8G дампи на 20G файловій системі і залишатися щасливими.

Як відбувається ротація насправді

systemd-coredump застосовує власну логіку збереження/видалення дампів, коли ліміти перевищені. Це добре, але це не миттєве квотування.
Якщо ви в циклі падінь, ви все одно хочете зупинити юніт, інакше ви будете чавити CPU і I/O, генеруючи дампи, що одразу видаляються.

ulimit, core_pattern і чому «на моєму ноуті працювало» вам бреше

Створення core-дампів має три шари, які постійно плутають:

Право ядра: чи дозволено взагалі дампування у цьому контексті збою?
Обмеження процесу: який максимальний розмір дампу процес може записати?
Обробник дампу: куди йде дамп і яка політика застосовується після створення?

Ліміти на рівні systemd юніта переважають вашу оболонку

Можна в shell зробити ulimit -c і почуватися продуктивно. Сервісу це байдуже. Для systemd-сервісів використовуйте:
LimitCORE= у файлі юніта або drop-in.

Приклад: обмежити дампи для одного сервісу, не торкаючись решти вузла:

cr0x@server:~$ sudo systemctl edit myservice.service

cr0x@server:~$ cat /etc/systemd/system/myservice.service.d/override.conf
[Service]
LimitCORE=512M

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart myservice.service

Значення: Навіть якщо процес великий, файл дампу не може перевищити 512M. Часто цього достатньо для корисної стек-траси.

Рішення: Для сервісів у циклі падінь негайно обмежте розмір, щоб зупинити зростання диска, зберігши при цьому відладну цінність.

core_pattern — це комутатор

Якщо /proc/sys/kernel/core_pattern передає в systemd-coredump, ваші очікування «де файли core?» потрібно змінити.
Ви знайдете їх під управлінням systemd, а не у вашому робочому каталозі.

Якщо в організації є кастомні обробники (завантажувачі, фільтри), перевірте їх. Поганий обробник може або «fail open» (скидати дампи), або «fail closed» (блокувати і гальмувати шлях виходу процесу). Жоден варіант не є приємним.

Стратегія зберігання: де повинні лежати дампи (і де не повинні)

Ставтеся до дампів як до міні-резервних копій пам’яті: великі, чутливі й іноді безцінні. Це пропонує кілька правил зберігання.

Правило 1: Не зберігайте дампи на крихітному /var, якщо можна уникнути

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

Правило 2: Виділений том кращий за героїчні чистки

Операційний виграш — у ізоляції: якщо дампи заповнять свою файлову систему, вузол все одно зможе логувати, оновлювати пакети, писати runtime-стан і відновлюватися.
Ви можете примонтувати виділений том в /var/lib/systemd/coredump або зробити bind-mount.

Приклад: створіть точку монтування і підтвердіть, що це окрема ФС (фактичне провізіонування залежить від вашого середовища):

cr0x@server:~$ sudo findmnt /var/lib/systemd/coredump
TARGET                       SOURCE    FSTYPE OPTIONS
/var/lib/systemd/coredump     /dev/sdb1 ext4   rw,relatime

Значення: Дампи ізольовані від /var загалом. Тепер ваш найгірший випадок — «більше дампів не приймається», а не «вузол мертвий».

Правило 3: Плануйте приватність (дампи — це дані)

Дамп може містити:

API-токени в пам’яті
Розшифровані корисні навантаження
Ідентифікатори клієнтів
Ключі шифрування (так, іноді)

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

Правило 4: Розгляньте збереження метаданих централізовано, а не дампів

У багатьох організаціях найкращий компроміс такий:

Залишати дампи локально короткий проміжок часу.
Зберігати лише метадані (час, виконуваний файл, юніт, сигнал, backtrace) в записах інцидентів або централізованих логах.
Копіювати дамп за межі хоста лише коли вирішили, що він потрібен.

Це уникає перетворення вашого лог-пайплайна на систему масового перенесення даних. Такі системи «завжди працюють», аж поки не перестають.

Три корпоративні міні-історії з шахт дампів

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія розгорнула новий образ на Debian для набору API-вузлів. Образ мав акуратну схему розділів: маленький root, окремий /var
і акуратний data-том для стану додатків. Всі відчували себе дорослими.

Через тиждень один вузол почав флапати. Не весь флот — тільки один. Він постійно перезапускав робочий сервіс, і за деякий час перестав реагувати на деплої. Потім перестав відповідати на логіни. Вузол не був «мертвий»; він просто не міг писати в ті місця, що важливі.

Неправильне припущення було простим: «дампи йдуть на data-том». Хтось колись бачив core-файли в директорії додатку й вирішив, що це досі дефолт. У цьому образі systemd-coredump зберігав дампи в /var/lib/systemd/coredump, а /var мав 10–20G.

Кожен збій створював багатогігабайтний стиснутий дамп. systemd перезапускав сервіс. Прийшло більше дампів. /var заповнилося. Journald почав скидати повідомлення. Оновлення пакетів не пройшли. Вузол не міг записувати достатньо стану, щоб коректно відновитися.

Виправлення не було хитрим: зупинити сервіс, зберегти один дамп, видалити решту і перемістити зберігання дампів на виділений монтуємий том. Потім затягнути KeepFree, щоб майбутні шторми падінь не могли задушити ОС. Більше виправлення було культурним: припинити припускати дефолти і почати перевіряти їх командами, що повертають факти.

Міні-історія 2: Оптимізація, що зіграла проти

Інша організація захотіла «кращої відладжуваності», тож глобально увімкнула дампи і підвищила ретеншн. Також вклали стиснення і підняли ліміти, бо «сховище дешеве».

Все було добре… поки реліз не приніс рідкісний збій у високопродуктивному процесі. Частота падінь не була величезною, але і не була малою. Під час пікових годин дампи генерувалися регулярно, кожен по кілька гігабайт навіть після стиснення.

Відкотився ефект з боку, який ніхто не змоделював: конкуренція за CPU під час відновлення. Стиснення великих дампів — це робота CPU. Коли почалися збої, система витрачала помітну частку CPU на стиснення знімків пам’яті, одночасно намагаючись скидати навантаження, перезапускати сервіси й обслуговувати трафік.

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

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Фінансова компанія мала нудну звичку, яку ніхто не святкував: у кожному критичному юніті був маленький systemd drop-in з ресурсними лімітами, включно з LimitCORE.
Це було частиною «шаблону золотого юніта», як таймаути і політики перезапуску.

Оновлення сторонньої бібліотеки спричинило segfault у бекграунд-сервісі на підмножині вузлів. Сервіс впав, systemd його перезапускав, і так — дампи з’явилися. Але вони були обмежені до кількох сотень мегабайт.

Вузли залишалися здоровими. Логи продовжували надходити. Депловання продовжувалися. Інцидент був дратівливим, але контрольованим. Інженери взяли один дамп, отримали backtrace, знайшли проблемну гілку коду і відкотили бібліотеку за графіком.

Ніхто не став героєм. Це і є суть. Нудні ліміти дозволили команді відлагодити, не жертвуючи доступністю. Це також заспокоїло команду безпеки, яка не панікувала через масивні знімки пам’яті на дисках.

Поширені помилки: симптом → корінь → виправлення

Це повторювані провали. Кожен включає конкретне виправлення, а не мотиваційну плакатку.

Помилка 1: «Диск повний, видаліть /var/log»

Симптом: Використання диска зростає швидко; логи звинувачують найперше; ви чистите журнали і завтра проблема повторюється.

Корінь: Core-дампи в /var/lib/systemd/coredump — справжній обсяг даних.

Виправлення: Виміряйте за допомогою du, потім обмежте і ротуйте дампи. Видаляйте дублікати тільки після того, як збережете принаймні один backtrace.

Помилка 2: «Вимкнути дампи глобально»

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

Корінь: Грубий відгук на тиск диска або проблеми приватності.

Виправлення: Залишайте дампи увімкненими, але з обмеженнями. Використовуйте пер-сервіс LimitCORE і системні MaxUse/KeepFree. Обробляйте дампи як чутливі та скорочуйте ретеншн.

Помилка 3: «Ми встановили MaxUse, тож ми в безпеці»

Симптом: Диск все одно доходить до 100% під час штормів падінь; вузли все ще нестабільні.

Корінь: Ліміти не працюють як миттєві квоти; цикл падінь продовжує генерувати нові дані, і ви ще й витрачаєте CPU.

Виправлення: Спочатку зупиніть offending юніт. Потім налаштуйте ретеншн. Ліміти не заміняють ізоляцію.

Помилка 4: «Дампи маленькі, бо вони стиснуті»

Симптом: Ви бачите .zst і думаєте, що все добре, поки не стає зовсім не добре.

Корінь: Коефіцієнт стиснення дуже варіюється; великі купи й маповані регіони все одно дають багатогігабайтні дампи.

Виправлення: Обмежуйте розмір. Перевіряйте реальні розміри файлів за допомогою ls -lhS. Не робіть висновків за розширенням.

Помилка 5: «Наш сервіс не може бути в циклі падінь; ми б помітили»

Симптом: Раптом у вас десятки дампів; сервіс здається «переважно робочим», бо балансувальник ховає один поганий вузол.

Корінь: Часткова відмова прихована надлишковістю; один вузол тихо дампить.

Виправлення: Налаштуйте оповіщення на частоту створення дампів і на цикли перезапуску юнітів з результатом core-dump. Під час тріажу використовуйте coredumpctl list.

Помилка 6: «Ми перемістили дампи з /var, зроблено»

Симптом: Розділ для дампів заповнюється, і тепер ви втрачаєте артефакти відладки — теж не ідеал.

Корінь: Ізоляція без ретеншну — це просто переміщення вогню.

Виправлення: Ізолюйте і встановіть MaxUse/KeepFree/ExternalSizeMax. Додайте моніторинг.

Чеклісти / покроковий план

Чекліст A: Під час активного інциденту «диск повний»

Підтвердіть, що саме повне: df -hT.
Визначте директорію з найбільшим зростанням: sudo du -xhd1 /var | sort -h.
Підтвердіть, що bulk — це дампи: sudo du -sh /var/lib/systemd/coredump.
Знайдіть винуватця: sudo coredumpctl list.
Зупиніть цикл падінь: systemctl status ..., потім systemctl stop ... або ізолюйте вузол.
Збережіть один репрезентативний дамп і метадані: coredumpctl info PID.
Отримайте backtrace, якщо можливо: coredumpctl gdb PID.
Видаліть дублікати, щоб відновити диск (точково).
Встановіть негайні ліміти ретеншну (coredump.conf.d).
Лише потім перезапустіть сервіс під контролем.

Чекліст B: Укріплення після інциденту (те, що запобігає повторенню)

Створіть або підтвердіть виділену файлову систему для дампів або принаймні достатній запас місця в /var.
Встановіть MaxUse і KeepFree на основі найменших вузлів, а не найбільших.
Встановіть ExternalSizeMax і/або пер-сервіс LimitCORE.
Визначте, хто має доступ до дампів і скільки вони зберігаються.
Переконайтеся, що debug-символи доступні там, де ви аналізуєте дампи (без перенесення повного тулчейну на кожен вузол).
Додайте оповіщення по:
- вільному місцю файлової системи для тому дампів
- частоті створення core-дампів
- циклам перезапуску systemd-юнітів з результатом core-dump
Документуйте правило «зберегти один дамп, очистити дублікати» у вашому ранбуці.

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

1) Чи варто відключати core-дампи в продакшні?

Зазвичай ні. Вимикайте вибірково, якщо маєте вагому причину (надчутливі робочі навантаження зі строгим контролем або якщо у вас уже є еквівалентна телеметрія падінь).
Спочатку віддавайте перевагу лімітам розміру й ретеншну.

2) Де Debian 13 зберігає core-дампи за замовчуванням?

Зазвичай під /var/lib/systemd/coredump/, коли використовується systemd-coredump. Підтвердіть через cat /proc/sys/kernel/core_pattern
і coredumpctl info.

3) Чому мої core-файли вже стиснуті, але все одно великі?

Тому що стиснення не змінює факту, що ви захоплюєте великий образ пам’яті. Великі купи, маповані файли і певні патерни пам’яті слабо стискуються.
Обмежте ExternalSizeMax і/або LimitCORE.

4) Який найшвидший спосіб ідентифікувати, що падає?

sudo coredumpctl list показує виконуваний файл і чи файл дампу присутній. Поєднайте з systemctl status, щоб виявити цикли перезапуску.

5) Чи можна зберігати лише метадані, а не повний дамп?

Так. Можна налаштувати поведінку сховища так, щоб лишались тільки метадані, але будьте обережні: коли знадобиться дамп, його не буде.
Поширений компроміс — зберігати невеликі обмежені дампи плюс метадані.

6) Як обмежити розмір дампу для одного сервісу, не змінюючи весь вузол?

Додайте systemd drop-in з LimitCORE=... для цього юніта. Це найчистіша операційна точка контролю для сервісів.

7) Чому диск все ще стрибає після встановлення MaxUse у coredump.conf?

Бо ви все ще можете швидко генерувати дампи під час циклу падінь, а застосування обмежень не є ідеальним миттєвим квотуванням. Спочатку зупиніть юніт, потім налаштовуйте ретеншн.
Ліміти зменшують стійке накопичення; ізоляція лікує шторм падінь.

8) Щодо приватності і секретів у дампах?

Припустіть, що дампи містять секрети. Обмежуйте доступ, скорочуйте ретеншн і уникайте широкого відправлення дампів. Трактуйте їх як чутливі артефакти інцидентів, а не як лог-файли.

9) Чи потрібні debug-символи на кожному production-вузлі?

Не обов’язково. Потрібен надійний спосіб символізувати стеки десь. Багато команд тримають символи в окремому середовищі для відладки й витягають необхідний дамп лише за потреби (з належним контролем доступу).

10) Чи безпечно видаляти core-дампи?

Так, після того як ви зберегли принаймні один репрезентативний дамп і зафіксували метадані/backtrace. Ризик не в стабільності системи, ризик — у втраті судової цінності. Будьте цілеспрямовані: збережіть один, видаліть дублікати.

Висновок: наступні кроки, що не кусаються пізніше

Core-дампи — це золото для відладки і криптоніт для операцій. Debian 13 дає інструменти, щоб зберегти золото і позбутися криптоніту, але не зробить це автоматично. Ви маєте обрати ліміти, що відповідають вашим дискам і толерантності інцидентів.

Зробіть це наступне, у такому порядку:

На одному вузлі перевірте, куди йдуть дампи і якими вони бувають: coredumpctl list, du -sh /var/lib/systemd/coredump.
Встановіть глобальний ретеншн: MaxUse і KeepFree у drop-in для coredump.
Встановіть пер-сервісні обмеження для підозрілих (великі купи, схильні до падінь): LimitCORE.
Ізолюйте сховище, якщо можливо: виділена ФС або монтування для дампів.
Зробіть це видимим: оповіщення про частоту дампів і цикли перезапуску з core-дампами.

Мета не «ніколи не генерувати дамп». Мета така: коли щось падає о 03:00, у вас є один корисний артефакт і вузол, що все ще завантажується.