используйте trace-cmd/ftrace, чтобы получить function_graph непосредственно перед тем, как произошло panic()

Я пытаюсь использовать trace-cmd для сбора дополнительной информации о сбое ядра, который я вижу. К сожалению, ядро ​​вылетает с сообщением "паника ядра - не синхронизация" (т. е. буферы сокетов и файлов не сбрасываются, поэтому все, что было в буферах во время сбоя, неизбежно теряется).

Есть ли способ:

  1. заставить процесс trace-cmd сбросить свои буферы в файловую систему или сокеты? ИЛИ ЖЕ
  2. сделать trace-cmd/ftrace, чтобы избежать буферизации (т.е. вызывать printk() за кулисами и использовать netconsole)?

Поскольку я запускаю эту команду trace-cmd в виртуализированной среде, меня не волнует, что жесткий диск может время от времени повреждаться, потому что я могу просто вернуться к последнему хорошему снимку или повторно развернуть виртуальную машину.


linux-kernel crash panic ftrace
person user389238    schedule 26.09.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Не могу гарантировать, что мой рецепт вам поможет, но кто знает :)

Сначала попробуйте разбуферить весь вывод trace-cmd. Вы можете найти несколько рецептов для этого здесь https://unix.stackexchange.com/questions/25372/turn-off-buffering-in-pipe

Во-вторых, ядро ​​считает, что запись FS при панике очень опасна, и это нормально, однако вы можете попытаться сохранить последние биты информации перед смертью за пределами разбившейся машины. Попробуйте перенаправить важную информацию на последовательный порт или сетевое соединение и перехватить ее с другой стороны. Нравиться

unbuffer trace-cmd >/dev/ttyS0

Другой способ — попытаться вообще избежать паники и позволить ядру работать дольше, но с непредсказуемым результатом. Вы можете отключить панику для нескольких случаев. Посмотрите настройки panic_on_* в каталоге /proc/sys/kernel/. Более подробную информацию можно найти в "Документация для /proc/sys/kernel/< /а>"

person MrCryo    schedule 30.09.2017
comment
Это не решило проблему, потому что я считаю, что между ftrace и trace-cmd есть еще один буфер. Unbuffer отключает только STDOUT, верно? - person user389238; 02.10.2017
comment
Да, конечно. Этот подход просто пытается уменьшить буферизацию. Другой способ — попытаться вообще избежать паники и позволить ядру работать дольше, но с непредсказуемым результатом. Вы можете отключить панику для нескольких случаев. Посмотрите настройки panic_on_в документации для /proc/sys/kernel/ (kernel.org/doc/Documentation/sysctl/kernel.txt). - person MrCryo; 02.10.2017