Документация<Предыдущая | Содержание: | Следующая>
6.6. Тестирование механизма аварийного дампа
Тестирование механизма аварийного дампа приведет к перезагрузка системы. В определенных ситуациях это может привести к потере данных, если система находится под большой нагрузкой. Если вы хотите протестировать механизм, убедитесь, что система простаивает или находится под очень небольшой нагрузкой.
Убедитесь, что СисРКК механизм активируется путем просмотра значения / proc / sys / ядро / sysrq параметр ядра:
кошка / proc / sys / ядро / sysrq
Если значение 0 возвращается дамп, а затем функция перезагрузки отключается. Значение больше, чем 1 указывает, что включен подмножество функций sysrq. Видеть /etc/sysctl.d/10-magic-sysrq.conf для подробного описания опций и значений по умолчанию. Включите дамп, а затем перезагрузите тестирование с помощью следующей команды:
sudo sysctl -w kernel.sysrq=1
Как только это будет сделано, вы должны стать пользователем root, просто используя Sudo будет недостаточно. Как корень пользователь, вам придется ввести команду echo c > /proc/sysrq-триггер. Если вы используете сетевое соединение, вы потеряете связь с системой. Поэтому тест лучше проводить при подключении к системной консоли.
Преимущество этого подхода состоит в том, что процесс дампа ядра становится видимым. Типичный результат теста должен выглядеть следующим образом:
Sudo -s
[sudo] пароль для Ubuntu:
# echo c > /proc/sysrq-триггер
[ | 31.659002] | SysRq: вызвать сбой |
[ | 31.659749] | ОШИБКА: невозможно обработать разыменование нулевого указателя ядра в |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | ПГД 3bfb9067 ПУД 368a7067 ПМД 0 |
[ | 31.662668] | Упс: 0002 [#1] SMP |
[ | 31.662668] | Процессор 1 |
[ | 31.659002] | SysRq: вызвать сбой |
[ | 31.659749] | ОШИБКА: невозможно обработать разыменование нулевого указателя ядра в |
[ | 31.662668] | IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20 |
[ | 31.662668] | ПГД 3bfb9067 ПУД 368a7067 ПМД 0 |
[ | 31.662668] | Упс: 0002 [#1] SMP |
[ | 31.662668] | Процессор 1 |
(Null)
....
Остальная часть вывода обрезается, но вы должны увидеть перезагрузку системы и где-то в журнале вы увидите следующую строку:
Начало: Сохранение vmcore после сбоя ядра...
После завершения система перезагрузится в нормальный рабочий режим. Затем вы найдете файл дампа ядра и связанные с ним подкаталоги в папке / var / сбой каталог:
лс /вар/сбой
201809240744 kexec_cmd linux-image-4.15.0-34-generic-201809240744.crash
Если дамп не работает из-за ошибки OOM (Out Of Memory), то попробуйте увеличить объем зарезервированной памяти путем редактирования /etc/default/grub.d/kdump-tools.cfg. Например, чтобы зарезервировать 512 мегабайт:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT аварийное ядро=384M-:512M"
пробег sudo update-grub а затем перезагрузитесь после этого и снова проверьте.