Вопрос или проблема
У меня есть встроенное устройство/система с процессором i.MX8M mini, работающим на базе Debian Linux с ядром версии 6.12.8.
Если я запускаю определенное программное обеспечение на этом устройстве, система зависает только через 1-3 дня работы. Изначально устройство сбрасывалось сторожевым таймером, но после отключения сторожевого таймера мы видим состояние “заморозки”. Да, функциональность сторожевого таймера работает нормально 🙂
Проблема только возникает с этим (довольно сложным) программным обеспечением. Запуская другие программы или ПО в течение недель, мы никогда не сталкивались с таким зависанием (у меня нет доступа к исходному коду этого программного обеспечения).
На терминале не отображается ошибка ядра, и в лог-файлах также нет никаких ошибок ядра. В состоянии “заморозки” система не реагирует на любые попытки подключения.
Мой вопрос: как пользовательский код может вызвать такое наблюдаемое состояние зависания системы, не вызывая паники ядра или каких-либо сообщений от ядра?
Или наоборот: если вас попросят написать пользовательский код, который полностью заморозит систему Linux без отображения каких-либо сообщений ядра, каким был бы этот код?
Возможно, система не зависла, а стала настолько медленной, что вы не видите никаких реакций.
Я предлагаю ограничить
- использование оперативной памяти
- использование процессора (приоритет)
- приоритет ввода/вывода
этого приложения. Возможно, это предотвратит “заморозку”.
Кроме того, я предлагаю запустить getty на последовательном порту.
Если вы графически отобразите использование оперативной памяти приложением с течением времени и увидите, что оно формирует пиловидный узор: постепенное увеличение без стабилизации на уровне, который соответствовал бы наивысшей нагрузке, и затем резкое снижение до начального уровня каждый раз, когда приложение перезапускается или система перезагружается, это обычно является признаком утечки памяти (или других ресурсов). Хорошая программа без утечек в конечном итоге стабилизируется на определенном уровне использования памяти, если (максимальная) нагрузка остается постоянной.
Если у проприетарного программного обеспечения есть доступ к какому-либо аппаратному устройству, ошибка в программном обеспечении может привести к “захвату” аппаратного устройства шины, к которой оно подключено. Если это основная системная шина, это, несомненно, зависнет систему, так как практически не будет возможности передать сообщение, если отсутствует активность шины.
(В ранней истории вычислительной техники для этого были “мигающие огни”: если ряд/матрица мигающих огней замерла в определенном состоянии, это означало, что процессор или системная шина зависли. К сожалению, современные системные шины работают на такой высокой частоте тактовых импульсов, что их невозможно контролировать человеческими органами чувств таким образом.)
Вы должны убедиться, что включена функциональность Magic SysRq, и разобраться, как послать сигнал BREAK на последовательный консольный порт. Когда система зависает, вы могли бы попробовать <BREAK> + L и/или <BREAK>+ W, чтобы увидеть, может ли ядро все еще выводить что-либо, и если да, то что выполняют процессоры в этот момент и есть ли какие-либо процессы, заблокированные без возможности прерывания.
Ответ или решение
Теория
Ситуация, когда устройство на базе i.MX8M mini с операционной системой Linux Debian и ядром 6.12.8 зависает, но не вызывает ошибки ядра, представляет собой сложную задачу диагностики. Когда возникает замерзание системы без паники ядра, возможные причины обычно связаны с программными и аппаратными аспектами взаимодействия операционной системы и пользовательского ПО. Основные причины могут включать в себя утечки памяти, неэффективное использование ресурсов (ЦП, память, дисковые операции), конфликты с внешними аппаратными устройствами или проблемы на уровне драйверов устройств.
Пример
В вашем случае система зависает через 1-3 дня после запуска определенного программного обеспечения. При отключении аппаратного сторожевого таймера вы обнаружили, что система "зависает", а не перезагружается. Также нет сообщения о панике ядра ни в терминале, ни в логах. Это указывает на то, что зависание может быть связано с одной из компенсаторных проблем, которые система не интерпретирует как критическую ошибку.
Применение
Анализ использования ресурсов
-
Память: Следует учитывать возможность утечки памяти. Если RAM используется без стабилизации на определенном уровне, особенно если график использования памяти показывает "зубчатый" паттерн, это говорит об утечке памяти. Это может произойти, если память, выделенная процессом, не освобождается корректно.
-
ЦП и I/O приоритеты: Пользовательское ПО может неэффективно использовать цикловые и I/O операции, что приводит к замедлению функций системы до точки, когда они становятся невосприимчивыми к входным сигналам. Ограничение ресурсов с помощью групп контроля (cgroups) может помочь и выявить зависимость производительности от использования ресурсов.
Аппаратные аспекты
-
Конфликт с устройствами: Программа может вызывать поведение, которое блокирует системную шину, делая систему невосприимчивой. Это может произойти, если ПО неправильно управляет периферийными устройствами или шина перенасыщается процессами ввода/вывода.
-
Состояние системы: Включение функции Magic SysRq и использование ее для получения отладочной информации может обозначить, выполняются ли какие-либо команды ядра или есть ли блокировки, которые не могут быть прерваны. Это особенно важно для понимания, являются ли процессы зависшими в ожидании завершения некий операции.
Диагностика
-
Сбор логов: Убедитесь, что все возможные системные логи ведутся как положено. Если ПО действительно зависает, логи могут не обновляться, но в них можно найти индикаторы проблем до момента, когда произойдет зависание.
-
Проверка версии программного обеспечения: Возможно, программное обеспечение содержит известные баги в вашей версии. Проверка с поставщиком или в сообществе может выявить схожие проблемы.
-
Отладка: Если доступен код, хотя бы частично, попробуйте использовать инструменты профилирования и отладки, такие как gdb, strace, для отслеживания поведения программного процесса.
Заключение
Таким образом, процесс выявления причины зависания системы без паники ядра может быть сложным и требовать систематического подхода. Это требуется для направления внимания на пользовательское ПО и его взаимодействие с оборудованием и ОС. Меры, такие как ограничение использования системных ресурсов, анализ логов, использование функций отладки и проверка оборудования, играют ключевую роль в выявлении и устранении проблемы.