Как диагностировать зависание линукса?
Скомпильте с -O0. Есть вероятность, что работать вообще перестанет, но будет понято в каком месте.
А что за ядро и какая архитектура процессора?
Из-за чего ещё может виснуть линуксИз-за проблем с железом и/или софтварных багов в ядре
Версия полугодовой давности те же самые компы не вешала, так что причина явно софтварная, но изменений за эти полгода было немеряно, так что тестировать нереально, особенно с учетом того, что иногда время до зависания составляет примерно сутки. Впрочем, иногда зависание случается и в течение минуты после запуска (может даже практически сразу), так что с этой стороны тоже непонятно, куда копать.А ядро за эти полгода меняли?
Вы ведь уже посмотрели дебаг логи своего приложения и ядра на предмет того что происходило прямо перед зависанием?
Вы ведь уже посмотрели дебаг логи своего приложения и ядра на предмет того что происходило прямо перед зависанием?Своего - не помогло. Ядра - пусто (если ты про kernel.log).
А что за ядро и какая архитектура процессора?Архитектура x86-64, ядро - дефолтное из убунты. Точную версию не скажу, в 12.04, 12.10 и 13.04 она разная.
Скомпильте с -O0. Есть вероятность, что работать вообще перестанет, но будет понято в каком месте.спасибо за свет, попробуем
> но изменений за эти полгода было немеряно, так что тестировать нереально
git bisect спешит к вам на помощь!
git bisect спешит к вам на помощь!
> но изменений за эти полгода было немеряно, так что тестировать нереальноначали несколько суток назад. Проблема в том, что время поджимает, а один круг тестирования занимает минимум сутки, а хочется же ещё тестировать и новые билды. Бисектом там на две недели минимум работы.
git bisect спешит к вам на помощь!
Архитектура x86-64, ядро - дефолтное из убунты. Точную версию не скажу, в 12.04, 12.10 и 13.04 она разная.
Проверена на многих компьютерах, с убунтой 12.04 (тут виснет чаще всего), 12.10, 13.04 и 13.10 (тут реже всего).Если железо исключаете (хотя я бы не стал так сразу этого делать), то изначально проблема в ядре, соответственно копать нужно ядро.
а) включите весь разумный дебаг (detect hung tasks, detect lockups, locking proof и т.д.), может что прояснится;
б) отрубите весь возможный power management (frequency scaling, PM/PM runtime и т.д.), протестируйте;
в) упростите операции с таймером, отрубите NO_HZ, HPET_TIMER, HIGH_RES_TIMERS и т.д., протестируйте.
Скорее всего что-то из вышеперечисленного должно помочь заворкэраундить проблему/сузить область для дальнейшего копания, если проблема/фикс не известны коммьюнити, и проблема нетривиальная, поиск и устранение проблемы может занять много времени, особенно у неспециалиста.
Запустите в VM и сделайте дамп памяти. Посмотрите причину в дампе.
Пример на VMWare - http://kb.vmware.com/selfservice/microsites/search.do?langua...
P.S. сам никогда не делал - гугл.
Пример на VMWare - http://kb.vmware.com/selfservice/microsites/search.do?langua...
P.S. сам никогда не делал - гугл.
Это, кстати, тоже хороший метод, под kvm замечательно дебажится ядро, главное, чтобы баг под vm воспроизводился.
Скомпильте с -O0. Есть вероятность, что работать вообще перестанет, но будет понято в каком месте.Кстати, а чем это должно помочь? Сервер-то зависает, а не падает. Дампа нет.
мб дебажить на второй машине через tty?
мб дебажить на второй машине через tty?Что дебажить? До момента зависания всё прекрасно. В момент зависания - уже поздно, машина зависла напрочь.
>> Скомпильте с -O0.
> Кстати, а чем это должно помочь?
Жить станет интереснее: к вашим проблемам добавится ещё
вероятность наткнуться на ошибки в компиляторе.
---
Q51: Hарод, а вы стабильным софтом пользоваться не пробовали?
A51: Пробовали, но мэйнфреймы с дизель-генераторами не везде есть.
> Кстати, а чем это должно помочь?
Жить станет интереснее: к вашим проблемам добавится ещё
вероятность наткнуться на ошибки в компиляторе.
---
Q51: Hарод, а вы стабильным софтом пользоваться не пробовали?
A51: Пробовали, но мэйнфреймы с дизель-генераторами не везде есть.
strace приложения?
strace приложения?А как его применить в данной ситуации? Можно его как-то заставить постоянно писать лог в файл?
UPD. Уже нашёл, всё понял. Будем пробовать.
а вот кстати неужели нет до сих пор специальных аппаратных средств для отладки зависаний? чтоб снять дамп памяти, заглянуть в регистры процессора и устройства опросить
Если железо исключаете (хотя я бы не стал так сразу этого делать), то изначально проблема в ядре, соответственно копать нужно ядро.я б наверное ещё попробовал процессоры как интел, так и амд,
а) включите весь разумный дебаг (detect hung tasks, detect lockups, locking proof и т.д.), может что прояснится;
б) отрубите весь возможный power management (frequency scaling, PM/PM runtime и т.д.), протестируйте;
в) упростите операции с таймером, отрубите NO_HZ, HPET_TIMER, HIGH_RES_TIMERS и т.д., протестируйте.
и сеть как физическую, так и виртуальную (то есть на одной машине через lo)
и сеть как физическую, так и виртуальную (то есть на одной машине через lo)А можно про это поподробнее? У нас же сервис сам к себе по сети не обращается - он посылает бродкасты, коннектится к другим устройствам и обслуживает запросы от внешнего контроллера. Это можно сэмулировать через виртуальную сеть?
ну для начала внешние устройства можно попытаться заменить заглушками и проверить, останется ли проблема
обслуживает запросы от внешнего контроллераА с внешним контроллером точно все хорошо?
Он как подцеплен? По USB? PCI?
А с внешним контроллером точно все хорошо?Всё исключительно по сети.
Он как подцеплен? По USB? PCI?
Это, кстати, тоже хороший метод, под kvm замечательно дебажится ядро, главное, чтобы баг под vm воспроизводился.Пока ни под одной виртуалкой баг не воспроизвелся, кстати.
Трафик до конечных устройств то дампите? Анализировали?
ну для начала внешние устройства можно попытаться заменить заглушками и проверить, останется ли проблемаПока попробовали заменить заглушками часть внешних устройств - вроде с пятницы до сих пор не зависло. Возможно, это сузит область поиска проблемы.
Трафик до конечных устройств то дампите? Анализировали?Весь трафик дампить нереально, там видеопотоки идут. За сутки с пары десятков камер набегут многие гигабайты.
ты так говоришь "гигабайты" как будто это что-то очень большое
Может он хотел сказать терабайты...
2 MBIT с камеры (условно) х 16 камер (условно) х сутки в среднем до зависания = 350 ГБ.
Не сказал бы, что задача непосильная, тем более, что проанализировать надо не все, а маленькую часть перед зависанием.
Не сказал бы, что задача непосильная, тем более, что проанализировать надо не все, а маленькую часть перед зависанием.
Пока ни под одной виртуалкой баг не воспроизвелся, кстати.Я бы, честно говоря, начал бы с кручения лимитов программе — объем сожранной памяти, число файловых дескрипторов, число форков. А то может оказаться, что аппаратные проблемы ни при чем: программа просто имитирует fork-bomb, что *выглядит* как зависание.
Я бы, честно говоря, начал бы с кручения лимитов программе — объем сожранной памяти, число файловых дескрипторов, число форков. А то может оказаться, что аппаратные проблемы ни при чем: программа просто имитирует fork-bomb, что *выглядит* как зависание.С этого мы начали, я уже писал. Есть случаи зависания сразу после старта, когда программа ещё ничего выжрать не успевает.
2 MBIT с камеры (условно) х 16 камер (условно) х сутки в среднем до зависания = 350 ГБ.х 24 тестовых компьютера? Но мы попробуем.
Мало ограничить количество файловых дескрипторов, еще число процессов надо регулировать.
Мало ограничить количество файловых дескрипторов, еще число процессов надо регулировать.Процесс один, тредов немного.
х 24 тестовых компьютера? Но мы попробуем.Да нет, не нужно. Это ж видео, и если в зависаниях действительно виноват трафик, то результат будет типа "если друг за другом приходят пакеты n и n+1, и результат xor байтов 0xff перврго пакета и 0xaa второго будет иметь 0, 2, 4, 6 биты равными единице, то сходит с ума стек udp, роняя ядро". Эмпирически отловить такое - без шансов, надо с другой стороны пытаться искать, что падает, а потом уже - почему.
Да нет, не нужно. Это ж видео, и если в зависаниях действительно виноват трафик, то результат будет типа "если друг за другом приходят пакеты n и n+1, и результат xor байтов 0xff перврго пакета и 0xaa второго будет иметь 0, 2, 4, 6 биты равными единице, то сходит с ума стек udp, роняя ядро". Эмпирически отловить такое - без шансов, надо с другой стороны пытаться искать, что падает, а потом уже - почему.Реализация UDP — тупее не бывает, ну и вообще навряд ли ошибка в протоколе, чтобы туда изначально глубоко копать, тем более такая ошибка в реализации протокола воспроизведётся и под vm.
Проверена на многих компьютерах, с убунтой 12.04 (тут виснет чаще всего), 12.10, 13.04 и 13.10 (тут реже всего).Многих - это сколько принципиально отличающихся и какие (мама, проц, видео)?
Все эти компы точно не виснут сами собой, а только от запуска вашего ПО?
Это чтобы откинуть глюки вида: http://www.howtoeverything.net/linux/hardware/random-freezes...
у меня есть два сервера с сетевухами intel (драйвер igb)
иногда они подвисают, один насовсем, другой на время, и это связано с нагрузкой
но на обоих при этом падает линк до свитча
вы смотрели на свитчах, с линком ок?
иногда они подвисают, один насовсем, другой на время, и это связано с нагрузкой
но на обоих при этом падает линк до свитча
вы смотрели на свитчах, с линком ок?
вот бы минимальный пример пощупать 
отличный эксплоит был бы, окажись это бага ядра или ещё что универсальное
отличный эксплоит был бы, окажись это бага ядра или ещё что универсальное
Все эти компы точно не виснут сами собой, а только от запуска вашего ПО?С предыдущей версией нашего ПО они не виснут.
В процессе анализа общего/различного хардвара, вырисовалась версия, похожая на правду: на всех компах есть вайфай-адаптер RTL8188CE, чей драйвер замечен в нестабильной работе (например, здесь ). Поскольку наш сервер регулярно ищет новые камеры по всем интерфейсам, то и к этому адаптеру он тоже обращается. Анализ логов показал, что непосредственно перед зависаниями была попытка сделать bind на интерфейс этого адаптера в то время, как сам интерфейс был в состоянии down. В норме bind должен вернуть ошибку, а не завесить комп, но всякое бывает... В предыдущей версии было то же самое, но в один поток (сейчас в два). Добавили предварительную проверку, компы работают больше суток, полет пока нормальный. Спасибо всем.
В предыдущей версии было то же самое, но в один поток (сейчас в два). Добавили предварительную проверку, компы работают больше суток, полет пока нормальный. Спасибо всем.Круто, че. Конгратс!
ну в принципе есть всякие полезные вещи типа NMI и XIR
Оставить комментарий
Dimon89
Ситуация: одна из написанных нами программ намертво вешает линукс. Намертво - значит даже SysRq-B не работает. Программа запускается не под рутом. Проверена на многих компьютерах, с убунтой 12.04 (тут виснет чаще всего), 12.10, 13.04 и 13.10 (тут реже всего). Программа - сетевой сервис, так что грешили на сетевой драйвер, но на машинах с другой сетевой картой программа тоже зависает (хотя и реже). Количество используемых файловых дескриторов тоже ограничили (на всякий случай). Связи с аппаратным перегревом не замечено. Из-за чего ещё может виснуть линукс и как это диагностировать?Версия полугодовой давности те же самые компы не вешала, так что причина явно софтварная, но изменений за эти полгода было немеряно, так что тестировать нереально, особенно с учетом того, что иногда время до зависания составляет примерно сутки. Впрочем, иногда зависание случается и в течение минуты после запуска (может даже практически сразу), так что с этой стороны тоже непонятно, куда копать.
UPD. В логах ядра пусто. Логи приложения детализируем и смотрим постоянно, но пока эффекта нет.