Как отлаживать демона под Linux? Можно ли подключиться к нему отладчиком? Какие вообще существуют отладчики, пригодные для этой цели?

Здравствуйте, Аноним, Вы писали:

А>Как отлаживать демона под Linux? Можно ли подключиться к нему отладчиком? Какие вообще существуют отладчики, пригодные для этой цели?

Обычно делают, чтобы программа могла запускаться не только в режиме демона, но и (с каким-нибудь ключом) просто интерактивно. Далее работают все обычные приёмы отладки, начиная от отладочного вывода.

Здравствуйте, Аноним, Вы писали:

А>Как отлаживать демона под Linux? Можно ли подключиться к нему отладчиком?

Можно, gdb /path/to/binary -p PID. Ну или kdbg вместо gdb.
Можно сделать ключик debug, с которым демон будет писать отладочные сообщения в syslog.
Можно сделать ключик для запуска без отрыва от терминала и писать отладочные сообщения в stdout.

Пишете обычное консольное приложение, далее при запуске используется в конце командной строки запуска & с сохранением pid или start-stop-daemon, daemon и другие системные методы установки консольных приложений как демоны...

На сегодняшний день нет инструментов отладки кода, содержащего в себе одну/несколько функций: fork() pthread*() exec*().
Скажу даже больше: никто не может гарантированно судить о поведении многопоточных приложений: можно лишь строить предположения.
Самый лучший совет — syslog().
Остальное придет с опытом.

Пардон, маленькая оговорочка: когда процесс запущен, к нему можно подключиться любым отладчиком из меню "attach to process-> process id"

Здравствуйте, Аноним, Вы писали:

А>Как отлаживать демона под Linux? Можно ли подключиться к нему отладчиком? Какие вообще существуют отладчики, пригодные для этой цели?

Debugging Forks:
http://sourceware.org/gdb/onlinedocs/gdb/Forks.html

читать про GDB (google gdb fork):

1. follow-fork-mode
   
2. detach-on-fork
   
3. follow-exec-mode

Здравствуйте, Аноним, Вы писали:

А>Как отлаживать демона под Linux? Можно ли подключиться к нему отладчиком? Какие вообще существуют отладчики, пригодные для этой цели?

В Linux есть куча полезных тулов для анализа поведения демона, которые могут
быть полезны когда нет доступа к исходникам или логгирование отсутствует (или
плохо реализовано, когда из логов ничего не понятно).
1) strace
Очень важный тул, который часто позволяет за 5 минут понять в чем проблема
Наиболее распространенные ситуации
— что-то возвращает EPERM, EACCES, EEXIST, etc
— висим на вызове connect или read
— кто-то убивает дочерние процессы
— проблема с блокировками (deadlocks, livelocks)
Иногда полезен бывает и ltrace.
2) Network & files tools
Демоны часто сетевые, так что нужно занать полезные тулы для сетевой отладки
— tcpdump/wireshark
— netstat/ip/route
— lsof
— ping/traceroute/nc/
— dig/nslookup
3) SystemTap
В случае, если тулы, описанные выше, не помогают, то можно использовать SystemTap
с фильтром по PID'у демона. Это пожалуй самый гибкий и информативный тул, но требует
некоторых знаний того, что лежит за сиситемными вызовами и вообще знаний ядра.

Все, что описано выше, — дополнение к хорошо продуманный системе логгирования.
Грамотные логи позволяют понять 90% проблем.

P.S.
IMHO, использование GDB не сильно помогает, разве что в довольно простых
случаях при анализе core дампов.

Здравствуйте, Аноним, Вы писали:

Пользуюсь eclipse'ом как для разработки, так и для отладки.

Лучшего backend'а для gdb под linux не видел.
+ ещё pretty printers

Здравствуйте, Alexander Pazdnikov, Вы писали:

AP>Здравствуйте, Аноним, Вы писали:

AP>Пользуюсь eclipse'ом как для разработки, так и для отладки.

AP>Лучшего backend'а для gdb под linux не видел.
AP>+ ещё pretty printers

Плохо смотрели!
Qt Creator

> AP>Лучшего backend'а для gdb под linux не видел.
> AP>+ ещё pretty printers <http://sourceware.org/gdb/wiki/STLSupport&gt;

Лучший бэкенд для GDB -- сам GDB.