Уже давно при интерактивной инсталляции RHEL/CentOS/Rocky и других дистрибутивов сразу после завершения процесса нам предлагают сконфигурировать Kdump. Некоторые инженеры от предложения отказываются – и зря. Участок резервируемой памяти не такой уж и большой, а при паниках системы или же зависаниях возможность создать дамп критически важна. Возникают неприятные ситуации, когда этот файл просто необходим. Случилась такая и у нас. Поэтому мы решили написать эту статью – о сrashdump’е и о том, для чего Kdump в Linux, как его правильно готовить и как с минимальными затратами подготовить стенд для последующего анализа дампов.
Что такое дамп и зачем он нужен?
Crash dump, kernel dump, kernel core dump, core dump, dump — это всё разные названия одного и того же файла, который создается, когда ОС приходит в состояние паники. Файл включает в себя необходимую для исследования проблемы информацию: заголовки программ, содержимое памяти, содержимое регистров CPU и т. д. Примерно в 99% случаев дампы имеют формат ELF (Executable and Linkable Format) – поэтому остановимся только на нем.
Операционные системы (ОС) тоже паникуют
Причин для паники не очень много:
1. ОС столкнулась с программной проблемой, которую не может решить. Чтобы не повредить данные, она уходит в панику.
2. ОС столкнулась с аппаратной проблемой.
3. ОС умышленно «спаниковали», чтобы получить дамп.
4. ОС зависла и watchdog «спаниковал» ее.
При каждом таком событии нам нужно сохранить состояние системы для последующего ее анализа.
Как ОС записывают дамп
Методов у операционки для создания дампов несколько:
1. Ядро ОС входит в состояние паники и самостоятельно записывает дамп.
2. Ядро ОС переключается в специальное диагностическое ядро, и уже оно записывает дамп.
3. Некая прошивка или гипервизор сохраняет содержимое памяти без участия ОС.
Например, в RHEL/CentOS/Rocky используется второй метод, что позволяет сохранять дамп, даже если проблема произошла в «основном» ядре.
А теперь к механике
Теперь отдельно стоит остановиться на механизме работы Kdump. После его активации наша система работает с двумя ядрами. Одно (first kernel) используется для работы, а под другое (dump-capture kernel) мы резервируем участок памяти. Это нужно для того, чтобы при аварии (естественной или искусственно вызванной пользователем) выполнить системный вызов kexec() и переключиться в него для последующего сохранения содержимого памяти. Для наглядности приводим симпатичную схему:
Про то, как установить и настроить Kdump, написано много статей и заметок, поэтому хочется только напомнить, что дамп может быть сохранен не только локально. В конфигурационном файле /etc/kdump.conf есть большая секция настроек:
[root@server-centos ~]# tail -20 /etc/kdump.conf
#raw /dev/vg/lv_kdump
#ext4 /dev/vg/lv_kdump
#ext4 LABEL=/boot
#ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937
#nfs my.server.com:/export/tmp
#ssh user@my.server.com
#sshkey /root/.ssh/kdump_id_rsa
path /var/crash
core_collector makedumpfile -l --message-level 1 -d 31
#core_collector scp
#kdump_post /var/crash/scripts/kdump-post.sh
#kdump_pre /var/crash/scripts/kdump-pre.sh
#extra_bins /usr/bin/lftp
#extra_modules gfs2
#default shell
#force_rebuild 1
#force_no_rebuild 1
#dracut_args --omit-drivers "cfg80211 snd" --add-drivers "ext2 ext3"
#fence_kdump_args -p 7410 -f auto -c 0 -i 10
#fence_kdump_nodes node1 node2По умолчанию благодаря настройкам нас балуют только «path» с указанием локальной папки и коллектором, позволяющим отфильтровать ненужные страницы памяти. Однако существуют ситуации, когда записать данные на локальную файловую систему не получится по нескольким причинам:
- проблема с дисковой подсистемой;
- проблема с файловой системой;
- нехватка места в /var/crash.
В таких случаях правильным enterprise-решением будет централизованное хранение дампов с сохранением их по сети. Для этого у нас есть два параметра на выбор — nfs и ssh.
Вот мы и получили dump. Что дальше?
В былые времена у нас был выбор: исследовать его самостоятельно или понести дамп вендору, чтобы он в нем сам покопался и предложил какое-то решение (или не предложил, тут уже как повезет). Сейчас приходится рассчитывать только на себя. Анализ дампа — это отдельная история, требующая много времени, кофе, слез и пушистого котика.
Но конечно же, без практической части мы вас не отпустим и рассмотрим создание стенда для анализа таких дампов для популярных клонов RHEL. Его можно делать на чём угодно: VMware, VirtualBox, KVM, Hyper-V -- на самом деле, это не имеет значения. Если у вас есть дамп, то его можно проанализировать в спокойной обстановке у себя в стенде.
Общий алгоритм прост:
1. Устанавливаем нужную ОС в виртуальную машину.
2. Устанавливаем все обновления.
3. Устанавливаем утилиту “crash”.
4. Устанавливаем “kernel-debuginfo” той же версии, что и на «спаниковавшем» сервере.
5. Загружаем в виртуальную машину дамп и анализируем. Тут очень подходит мем про рисование совы:
1. Если понадобится проанализировать дамп другого сервера с более поздним ядром, то обновляем “kernel-debuginfo”. Если с более ранним, то “yum remove kernel-debuginfo*”, и ставим нужную нам версию (помните: одновременно может быть установлена только одна версия).
В основном мы ориентировались на документацию от Red Hat, статья же о клонах:
· Какие версии с какими ядрами выходили https://access.redhat.com/articles/3078
· RHEL 6 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-kdump-crash
· RHEL 8 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/analyzing-a-core-dump_managing-monitoring-and-updating-the-kernel#doc-wrapper
· RHEL 9 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/analyzing-a-core-dump_managing-monitoring-and-updating-the-kernel#doc-wrapper
Теперь разберем на примерах (для архитектуры x86_64).
**CentOS 6**
Да, он уже EOL, но в корпоративных дата-центрах не редкость (там и не такое попадается). Скачиваем нужные образ и контрольную сумму, проверяем:
· https://vault.centos.org/6.10/isos/x86_64/CentOS-6.10-x86_64-minimal.iso
· https://vault.centos.org/6.10/isos/x86_64/sha256sum.txt
Установку можно проводить с параметрами по умолчанию. Советую делать это на странице, где будут спрашивать имя сервера: нажать Configure Network и настроить сеть. В противном случае вам придется делать это после установки и вручную править файлы в “/etc/sysconfig/network-scripts/”. В более поздних версиях мы имеем NetworkManager из коробки даже в минимальных комплектациях, так что через `nmtui` можно будет легко настроить сеть.
Теперь нам понадобятся рабочие репозитории. Они настраиваются неочевидно из-за того, что версия ОС стала EOL (от root):
```
cd /etc/yum.repos.d/
mkdir old
mv *.repo old/
mv old/CentOS-Debuginfo.repo .
sed -i 's/enabled=0/enabled=1/' CentOS-Debuginfo.repo
vi c610.repo
```Прописываем вот такие репозитории:
Hidden text
```
[CentOS_6.10_base]
name=CentOS 6.10 Base
baseurl=http://vault.epel.cloud/6.10/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[CentOS_6.10_updates]
name=CentOS 6.10 Updates
baseurl=http://vault.epel.cloud/6.10/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[CentOS_6.10_extras]
name=CentOS 6.10 Extras
baseurl=http://vault.epel.cloud/6.10/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=1
metadata_expire=never
[CentOS_6.10_contrib]
name=CentOS 6.10 Contrib
baseurl=http://vault.epel.cloud/6.10/contrib/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=0
metadata_expire=never
[CentOS_6.10_centosplus]
name=CentOS 6.10 CentOSPlus
baseurl=http://vault.epel.cloud/6.10/centosplus/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
enabled=0
metadata_expire=never
```Это включит архивные репозитории из CentOS Vault. Ранее мы включили до сих пор не убранный в архив репозиторий для дебага. Теперь осталось только “yum update -y && yum install -y crash && reboot”, и у нас получится готовая заготовка для стенда. Будет нелишним сделать снэпшот получившейся виртуальной машины.
Теперь представим, что у нас спаниковал сервер с CentOS 6.2 и ядром `2.6.32-220`. Нам нужно проанализировать дамп. В этом случае берем `yum install kernel-debuginfo-2.6.32-220.el6.x86_64`, потом грузим на виртуальную машину файл `vmcore`, используем:
`
# crash /usr/lib/debug/lib/modules/2.6.32-220.el6.x86_64/vmlinux /путь/до/собранного/с/упавшего/сервера/vmcoreФайл дампа на спаниковавшем сервере будет в “/var/crash/timestamp/vmcore”, если вы не меняли настройки. Если не получается определить точное название нужного пакета для анализа, смотрите, какие есть в http://debuginfo.centos.org/6/x86_64/.
**CentOS 7**
Тут проще, так как он еще поддерживается. Качаем и проверяем контрольную сумму (можно и с другого зеркала):
· https://mirror.yandex.ru/centos/7.9.2009/isos/x86_64/CentOS-7-x86_64-Minimal-2009.iso
· https://mirror.yandex.ru/centos/7.9.2009/isos/x86_64/sha256sum.txt
Затем ставим от root :
# sed -i 's/enabled=0/enabled=1/' /etc/yum.repos.d/CentOS-Debuginfo.repo && yum update -y && yum install -y crash && rebootЧто же касается установки `kernel-debuginfo` и дальнейшего анализа, всё по аналогии с CentOS 6. Имена пакетов можно посмотреть на http://debuginfo.centos.org/7/x86_64/
**CentOS 8.5**
Речь пойдет о EOL классической версии, что перестали поддерживать вопреки обещаниям не в 2028 году, а в 2021-м: https://blog.centos.org/2020/12/future-is-centos-stream/ . Тем не менее многие люди успели себе ее поставить. Начинаем как обычно, качаем и проверяем контрольную сумму:
· https://vault.centos.org/8.5.2111/isos/x86_64/CentOS-8.5.2111-x86_64-boot.iso
· https://vault.centos.org/8.5.2111/isos/x86_64/CHECKSUM
Так как это EOL, то с netinstall, что мы скачали, придется после настройки сети указать место для скачивания пакетов руками в Installation Source:
https://vault.centos.org/8.5.2111/BaseOS/x86_64/os/
и указать в Software Selection, что нам нужен Minimal Install.
После установки придется снова вручную настраивать архивные репозитории от root:
```
cd /etc/yum.repos.d/
mkdir old
mv *.repo old/
mv old/CentOS-Linux-Debuginfo.repo .
sed -i 's/enabled=0/enabled=1/' CentOS-Linux-Debuginfo.repo
vi c85.repo
```Прописываем вот такие репозитории:
```
[baseos]
name=CentOS Linux 8.5 - BaseOS
baseurl=https://vault.centos.org/8.5.2111/BaseOS/x86_64/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
metadata_expire=never
[appstream]
name=CentOS Linux 8.5 - AppStream
baseurl=https://vault.centos.org/8.5.2111/AppStream/x86_64/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
metadata_expire=never
```После этого достаточно выполнить:
# yum update -y && yum install -y crashУстановку `kernel-debuginfo` и дальнейший анализ делаем по аналогии с CentOS 6. Имя пакетов можно посмотреть на http://debuginfo.centos.org/8/x86_64/Packages/.
**Rocky Linux 8**
Качаем и проверяем сумму (можно и с другого зеркала):
· https://mirror.yandex.ru/rockylinux/8.9/isos/x86_64/Rocky-8.9-x86_64-minimal.iso
· https://mirror.yandex.ru/rockylinux/8.9/isos/x86_64/CHECKSUM
Ставим:
# yum update -y && yum install -y crashА вот с репозиториями для `kernel-debuginfo` сложнее, так как в отличие от CentOS нет общего для всех подверсий каталога с отладочными файлами, он отдельный для каждой подверсии.
Если нужны отладочные заголовки для текущего ядра из 8.9, то достаточно включить текущий репозиторий отладки для BaseOS и вставить из него:
Hidden text
```
[root@localhost ~]# uname -r
4.18.0-513.5.1.el8_9.x86_64
[root@localhost ~]# head /etc/yum.repos.d/Rocky-Debuginfo.repo
# Rocky-Debuginfo.repo
#
[baseos-debug]
name=Rocky Linux $releasever - BaseOS - Source
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever-debug
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/debug/tree/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial
[root@localhost ~]# vi /etc/yum.repos.d/Rocky-Debuginfo.repo
[root@localhost ~]# head /etc/yum.repos.d/Rocky-Debuginfo.repo
# Rocky-Debuginfo.repo
#
[baseos-debug]
name=Rocky Linux $releasever - BaseOS - Source
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever-debug
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/debug/tree/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial
[root@localhost ~]# yum update
Rocky Linux 8 - BaseOS - Source 5.1 kB/s | 3.1 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost ~]# yum install kernel-debuginfo-4.18.0-513.5.1.el8_9.x86_64
Last metadata expiration check: 0:00:23 ago on Mon 27 Nov 2023 01:28:28 PM MSK.
Dependencies resolved.
==================================================================================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================================================================================
Installing:
kernel-debuginfo x86_64 4.18.0-513.5.1.el8_9 baseos-debug 657 M
Installing dependencies:
kernel-debuginfo-common-x86_64 x86_64 4.18.0-513.5.1.el8_9 baseos-debug 75 M
Transaction Summary
==================================================================================================================================================================================================
Install 2 Packages
Total download size: 732 M
Installed size: 3.8 G
Is this ok [y/N]: n
Operation aborted.
[root@localhost ~]#
```Имена доступных пакетов можно посмотреть тут: https://mirror.yandex.ru/rockylinux/8.9/BaseOS/x86_64/debug/tree/Packages/k/
А вот если нужны заголовки для более старой версии, то придется подключать уже архив. Вот пример для 8.7:
Hidden text
```
[root@localhost ~]# vi /etc/yum.repos.d/debug87.repo
[root@localhost ~]# yum update
Rocky Linux 8.7 - BaseOS - Source 1.2 MB/s | 3.3 MB 00:02
Last metadata expiration check: 0:00:01 ago on Mon 27 Nov 2023 01:34:51 PM MSK.
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost ~]# cat /etc/yum.repos.d/debug87.repo
[baseos-8.7-debug]
name=Rocky Linux 8.7 - BaseOS - Source
baseurl=https://dl.rockylinux.org/vault/rocky/8.7/BaseOS/x86_64/debug/tree/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial
[root@localhost ~]# yum install kernel-debuginfo-4.18.0-425.13.1.el8_7.x86_64
Last metadata expiration check: 0:00:47 ago on Mon 27 Nov 2023 01:34:51 PM MSK.
Dependencies resolved.
==================================================================================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================================================================================
Installing:
kernel-debuginfo x86_64 4.18.0-425.13.1.el8_7 baseos-8.7-debug 638 M
Installing dependencies:
kernel-debuginfo-common-x86_64 x86_64 4.18.0-425.13.1.el8_7 baseos-8.7-debug 72 M
Transaction Summary
==================================================================================================================================================================================================
Install 2 Packages
Total download size: 710 M
Installed size: 3.7 G
Is this ok [y/N]: n
Operation aborted.
[root@localhost ~]#
```Посмотреть возможные версии kernel-debuginfo можно тут: https://dl.rockylinux.org/vault/rocky/8.7/BaseOS/x86_64/debug/tree/Packages/k/
Для 8.8, 8.6 и более старых делаем по аналогии.
**Rocky Linux 9**
Качаем и проверяем сумму (можно и с другого зеркала):
+ https://mirror.yandex.ru/rockylinux/9.3/isos/x86_64/Rocky-9.3-x86_64-minimal.iso
+ https://mirror.yandex.ru/rockylinux/9.3/isos/x86_64/CHECKSUM
Потом ставим `dnf update -y && dnf install -y crash`. А вот с репозиториями для `kernel-debuginfo` делаем наподобие 8.9. Для текущей версии:
Hidden text
```
[root@localhost ~]# uname -r
5.14.0-362.8.1.el9_3.x86_64
[root@localhost ~]# grep -A8 baseos-debug /etc/yum.repos.d/rocky.repo
[baseos-debug]
name=Rocky Linux $releasever - BaseOS - Debug
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever-debug$rltype
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/debug/tree/
gpgcheck=1
enabled=0
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
[root@localhost ~]# vi /etc/yum.repos.d/rocky.repo
[root@localhost ~]# grep -A8 baseos-debug /etc/yum.repos.d/rocky.repo
[baseos-debug]
name=Rocky Linux $releasever - BaseOS - Debug
mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever-debug$rltype
#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/debug/tree/
gpgcheck=1
enabled=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
[root@localhost ~]# dnf update
Rocky Linux 9 - BaseOS 6.0 kB/s | 4.1 kB 00:00
Rocky Linux 9 - BaseOS - Debug 774 kB/s | 854 kB 00:01
Rocky Linux 9 - AppStream 8.6 kB/s | 4.5 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost ~]# dnf install kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64
Last metadata expiration check: 0:00:31 ago on Mon 27 Nov 2023 02:13:43 PM MSK.
Error:
Problem: conflicting requests
- nothing provides kernel-debuginfo-common-x86_64 = 5.14.0-362.8.1.el9_3 needed by kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64 from baseos-debug
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@localhost ~]#
```Здесь, как видите, нарываемся на ошибку, которая находится на стороне разработчиков Rock (забыли собрать нужный пакет). Пакета просто нет в https://mirror.yandex.ru/rockylinux/9.3/BaseOS/x86_64/debug/tree/Packages/k/.
К счастью, этот изъян можно поправить, скачав пакет и распаковав его:
```
[root@localhost ~]# dnf download kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64
Last metadata expiration check: 0:09:10 ago on Mon 27 Nov 2023 02:13:43 PM MSK.
kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64.rpm 3.7 MB/s | 611 MB 02:44
[root@localhost ~]# ls
anaconda-ks.cfg kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64.rpm
[root@localhost ~]# mkdir 5.14.0-362.8.1.el9_3
[root@localhost ~]# mv kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64.rpm 5.14.0-362.8.1.el9_3/
[root@localhost ~]# cd 5.14.0-362.8.1.el9_3/
[root@localhost ~]# rpm2cpio kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64.rpm | cpio -idmv
### тут был длинный вывод, что я удалил (можете без -v запускать, тогда не будет)
[root@localhost 5.14.0-362.8.1.el9_3]# ls -l
total 625776
-rw-r--r--. 1 root root 640792453 Nov 27 14:25 kernel-debuginfo-5.14.0-362.8.1.el9_3.x86_64.rpm
drwxr-xr-x. 3 root root 17 Nov 27 14:29 usr
[root@localhost 5.14.0-362.8.1.el9_3]# ls usr/lib/debug/lib/modules/5.14.0-362.8.1.el9_3.x86_64/
internal kernel partner vdso vmlinux
[root@localhost 5.14.0-362.8.1.el9_3]#
```Как видим, у нас сейчас в `/root/5.14.0-362.8.1.el9_3/usr/lib/debug/lib/modules/5.14.0-362.8.1.el9_3.x86_64/` лежит искомый `vmlinux`. Можно будет `crash /root/5.14.0-362.8.1.el9_3/usr/lib/debug/lib/modules/5.14.0-362.8.1.el9_3.x86_64/ /путь/до/собранного/с/упавшего/сервера/vmcore`
Если же нужно проанализировать дамп более старого ядра из состава Rocky 9.0, то по аналогии с 8.7 выше настраиваем архивный репозиторий:
```
[root@localhost ~]# vi /etc/yum.repos.d/debug90.repo
[root@localhost ~]# cat /etc/yum.repos.d/debug90.repo
[baseos-debug-9.0]
name=Rocky Linux 9.0 - BaseOS - Debug
baseurl=https://dl.rockylinux.org/vault/rocky/9.0/BaseOS/x86_64/debug/tree/
gpgcheck=1
enabled=1
metadata_expire=6h
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9
[root@localhost ~]# dnf update
Rocky Linux 9.0 - BaseOS - Debug 632 kB/s | 863 kB 00:01
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost ~]# dnf install kernel-debuginfo-5.14.0-70.30.1.el9_0.x86_64
Last metadata expiration check: 0:00:04 ago on Mon 27 Nov 2023 02:44:37 PM MSK.
Error:
Problem: conflicting requests
- nothing provides kernel-debuginfo-common-x86_64 = 5.14.0-70.30.1.el9_0 needed by kernel-debuginfo-5.14.0-70.30.1.el9_0.x86_64 from baseos-debug-9.0
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@localhost ~]#
```Как видим из https://dl.rockylinux.org/vault/rocky/9.0/BaseOS/x86_64/debug/tree/Packages/k/: тут тоже не собран нужный пакет. По аналогии скачиваемся и распаковываем.
В наших планах написать еще один материал о Kdump. Он будет посвящен анализу одного любопытного кейса из нашей практики.