[C++, Linux] Автокрэшрепорт
google watchdog script linux
Есть некий демон, который в отдельные неведомые моменты своего существования падает.Не лечится.
Даже не пытайся. Вычищай говнокод порциями, медленно переписывая начисто. И под валгриндом запускай НА ВСЁМ ПРОЦЕССЕ РАЗРАБОТКИ.
Причина простая: скорее всего ломается стек, а падает в другом месте. Хуй отследишь, не трать время зря. Место падения и bt тебе НИЧЕГО не даст.
watchdog мне разве что сообщит, что сервис умер, а мне надо знать, почему.
Да вот в том-то и печалька, что код унаследованный, написан тоже на страшной смеси сей и плюсов и для меня он является в общем-то очень побочной задачей. Иногда этот демон-сервер у заказчика падает, они жалуются и тогда я отправляюсь искать, что произошло. Как бы в лог падает, что "double free or corruption", а где конкретно — загадка.
Переписывать всё возможности особой нет, потому что "неприоритетная задача".
Переписывать всё возможности особой нет, потому что "неприоритетная задача".
watchdog мне разве что сообщит, что сервис умер, а мне надо знать, почему.Почему — позже установишь по дампу, который watchdog тебе отправит
А как разрешить корки - это в маны
Как бы в лог падает, что "double free or corruption", а где конкретно — загадка.Ясно где. Рушится стек, это всё как-то работает (месяцами) и потом где-то выползает в левом месте.
Искать такие баги можно только тотальной декомпозицией.
Переписывать всё возможности особой нет, потому что "неприоритетная задача".
Не берись за задачу. А то сам не сделаешь ничего, и потом будешь оправдываться "за что ЗП получаешь".
В приват пиши, если интересны детали.
А как разрешить корки - это в маныА с чего ты взял что там вообще bt будет нормальный? Говнокод потому и говнокод, что дебагу уже не подлежит.
пианист, сам знает, когда за задачу стоит браться, а когда — нет.
его вопрос несколько о другом, если я правильно понял.
его вопрос несколько о другом, если я правильно понял.
Не берись за задачу. А то сам не сделаешь ничего, и потом будешь оправдываться "за что ЗП получаешь".Пианист, ты конечно клёвый, но тут вопрос не из серии, "за что ЗП получаю". Вопрос стоит так: есть продукт, которым НИКТО не занимается. У всех есть много других задач, за которые люди собственно и получают деньги. Но порой приходит начальник и говорит: "слушай, тут люди, которые у нас это купили, жалуются, что упало, пофиксь, а".
Отдельная тулза не вариант. Я могу что-то добавить только в новую версию продукта.
пианист, сам знает, когда за задачу стоит браться, а когда — нет.Иногда можно взяться за задачу и сточить зубы. Отладка трешового кода в моей практике ни разу не приводила к стабильной проге.
Но порой приходит начальник и говорит: "слушай, тут люди, которые у нас это купили, жалуются, что упало, пофиксь, а".Сложно сказать.
Я бы сделал так.
1. Посмотрел код, оценил бы его с разных сторон
2. Если код совсем не годный, то сказал бы так: "извини, начальнег, не берусь"
3. Если код в принципе адекватный, то начал бы рефакторинг и добивался бы работы 100% чистоты под валгриндом
Моя мысль простая: крутой прогер — не тот, кто много знает и умеет, а тот, кто умеет оценивать задачи по плечу и не браться за совсем провальные. Пойми, что взяться и не сделать задачу — хуже, чем просто отказаться от неё.
Отдельная тулза не вариант. Я могу что-то добавить только в новую версию продукта.И что тебе мешает добавить эту тулзу в новую версию проекта?
Я делал когда-то сабаяку, которая бдела демон и если он сегфолтился перезапускала и делала что-то еще (не помню уже). При этом она сама порождала второй процесс, то есть это была не внешняя тулза, а часть main'а (микроскопическая). В принципе, никто тебе не мешает просто заловить SEGV и в обработчике сбросить всю память вручную...
Сейчас, конечно, стыдно
Но что поделать, был маленький и глупый Отладка трешового кода в моей практике ни разу не приводила к стабильной проге.в моей приводила.
собственно, тут еще тоже вопрос субъективный.
я вот и твой код считаю очень трешовым.
ну по сути ты правильно все сказал про оценку своих возможностей.
я просто к тому, что у , судя по постам на форуме, с этим все окей.
И под валгриндом запускай НА ВСЁМ ПРОЦЕССЕ РАЗРАБОТКИ.кроме valgrind и tsan могу посоветовать clang static analyzer. Очень крутая штука.
Меньше недели назад он нашел в коде нашего проекта тот самый double free.
К сожалению, это далеко не последняя бага, которую он нашел и которая еще не закрыта.
да, таких штук кстати много бывает всяких.
все хочу их попробовать тоже ради развлечения.
все хочу их попробовать тоже ради развлечения.
2. Если код совсем не годный, то сказал бы так: "извини, начальнег, не берусь"слабак
слабакВот кто на это ведётся — точно слабак.
я просто к тому, что у , судя по постам на форуме, с этим все окей.Такой комплимент от Бачана. Блин, моё чсв сейчас резко стартанёт вверх.
И что тебе мешает добавить эту тулзу в новую версию проекта?Вот. Вот именно про это и был вопрос. Как правильно (я же так понимаю, ты предлагаешь просто форкнуться и как-то это делать во втором процессе?) отловить падение родителя, со всей коркой и стэктрейсом. Насколько я могу предположить, в моём обработчике SEGV/ABRT/etc. стэктрейс у меня сохранится и его можно сдампить, а вот как правильно слить всю память?
Я делал когда-то сабаяку, которая бдела демон и если он сегфолтился перезапускала и делала что-то еще (не помню уже). При этом она сама порождала второй процесс, то есть это была не внешняя тулза, а часть main'а (микроскопическая). В принципе, никто тебе не мешает просто заловить SEGV и в обработчике сбросить всю память вручную...
Сейчас, конечно, стыдно
Лучше пусть родитель следит за ребенком. Выставить ему rlimit на размер коры повыше, и после смерти отослать куда надо.
Не понял зачем обработчики - в коре и так будет все что надо.
Не понял зачем обработчики - в коре и так будет все что надо.
Как, как? Есть чужая неопределенная машина, из которой моего есть только демон. Некоторые дистрибутивы, вроде как, вообще не сохраняют корку, а убунта, например (да, у заказчика она тоже есть) скармливает корку через пайп в аппорт. Я не могу влиять на их конфиги, я могу только своими средствами как-то попытаться всё собрать и отправить самому себе.
Есть чужая неопределенная машина, из которой моего есть только демон.Еще раз. В принципе тебе не очень важно, кто за кем следит - родитель за ребенком или наоборот.
Только в первом случае это просто, во втором - сложно.
Не думаю что для остальной системы важно, кто у тебя собака, а кто - рабочий демон.
Менять конфиги (в некоторых пределах) ты можешь, через setrlimit(2) в родительском процессе.
Это понятно. А вот на core_pattern я влиять же не могу. Корка создаётся и пайпом скармливается в какую-нибудь задницу aka девнуль или что-то к нему приводящее. В убунте это, например, apport, который в релизных убунтах по умолчанию выключен, поэтому любые корки как раз таки и отправит в девнуль.
Что-то я отстал от прогресса
Ну тогда остается только перехват SEGV и ручной дамп памяти или какую-нибудь фигню типа gcore(1)...
Ну тогда остается только перехват SEGV и ручной дамп памяти или какую-нибудь фигню типа gcore(1)...
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
В 2.6.19 такую возможность добавили. JFYI
а нормального доступа к машине клиенты не могут предоставить? о какой тогда отладке речь.
Клиенты логи-то со скрипом выдают
Высокая секурность, паранойя по поводу того, к каким данным мы можем доступ получить и всё такое. Я подозреваю, что их еще придётся убеждать дать демону возможность просто репорт отослать-то, а то с них станется ему всю активность файрволлом зарезать.
Высокая секурность, паранойя по поводу того, к каким данным мы можем доступ получить и всё такое. Я подозреваю, что их еще придётся убеждать дать демону возможность просто репорт отослать-то, а то с них станется ему всю активность файрволлом зарезать.
Клиенты логи-то со скрипом выдаютУ тебя сам демон-то есть? Почему не запустишь у себя локально и не отладишь?
Потому что локально он у меня не падает, блин Я же говорю, баг проявляется эпизодически, хрен знает где. Как ты сам верно сказал, где-то косяк с памятью, а вылезет это еще хз когда.
Переписывать весь код я не буду, это потребует дохрена времени. Я не идеалист, чтобы сидеть полировать код, мне надо тупо решить конкретную задачу.
Я же говорю, баг проявляется эпизодически, хрен знает где. Как ты сам верно сказал, где-то косяк с памятью, а вылезет это еще хз когда.Переписывать весь код я не буду, это потребует дохрена времени. Я не идеалист, чтобы сидеть полировать код, мне надо тупо решить конкретную задачу.
Ставь сборку с символами, и пусть клиенты-параноики сами следят за падениями и с корок бектрейсы снимают (предварительно разрешив корки).
Кстати еще рецепт.
Вешаешь обработчик на 11 сигнал (или по какому он падает? в котором с помощью ф-ции backtrace из execinfo.h распечатываешь бектрейс и отправляешь его себе.
Вешаешь обработчик на 11 сигнал (или по какому он падает? в котором с помощью ф-ции backtrace из execinfo.h распечатываешь бектрейс и отправляешь его себе.
Ох ты ж ё. Я и не знал, что есть такая функция. Сколько нам открытий чудных.
Оставить комментарий
doublemother
Есть некий демон, который в отдельные неведомые моменты своего существования падает. Поскольку работает он автономно, иногда вообще на каких-то далеких машинах, хотелось бы выяснить причины падения.Подобное умеют убунтовский apport и федоровский abrt, но первый на питоне, а второй вообще на каком-то ужасном ульрихдрепперстайл c/c++ с кучей ненужного функционала — в его коде я просто потерялся, не найдя того, что нужно.
Отсюда вопрос: как бы мне при падении софтины получить бэктрейс, или даже коредамп, чтобы автоматически отослать их по назначению. Можно ли это сделать прямо из самого процесса демона (не изменится ли при этом стэктрейс?) или нужен отдельный процесс, который будет мониторить состояние основного?
Если есть какие-нибудь ссылки на описание, как это в линуксе сделать, буду премного благодарен.