LINUX.ORG.RU

Контроль процессов и потоков


0

0

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

Так же всю доступную информацию по ошибке.

Это делается через прерывания? Необходимо ли писать модуль ядра? В какую вообще сторону копать?

Я системным программированием никогда не занимался, в основном прикладным. Но поставили такую задачу...

Посоветуйте что-нибудь =)

> Это делается через прерывания? Необходимо ли писать модуль ядра? В какую вообще сторону копать?

Звучит уж больно дико.

Может просто настроить выпадение core файлов(при падении процесса на диск сбрасывается содержимое его памяти, которую можно будет отлаживать дебагером) или подключать к каждому отслеживаемому процессу gdb/gdbserver со скриптом? В таком случае и писать ни чего не потребуется.

YesSSS ★★★
()
Ответ на: комментарий от YesSSS

> Может просто настроить выпадение core файлов(при падении процесса на диск сбрасывается содержимое его памяти, которую можно будет отлаживать дебагером) или подключать к каждому отслеживаемому процессу gdb/gdbserver со скриптом? В таком случае и писать ни чего не потребуется.

Не, дебагер использовать нельзя.
Неужели никак нельзя получить от ОС сообщение о падении какого-либо процесса?

dogmeat-fall
() автор топика
Ответ на: комментарий от YesSSS

> Звучит уж больно дико.

В моем случае написание демона/модуля будет более правильное решение, чем городить костыли из дебагеров и т.п.

dogmeat-fall
() автор топика
Ответ на: комментарий от dogmeat-fall

> Не, дебагер использовать нельзя.

Чит, слишком просто? =) Расскажи тогда подробнее что использовать можно, что нельзя и какую именно инфу ты хочешь получать. Лезть в модули ядра в данном случае - как из пушки по воробьям.

YesSSS ★★★
()
Ответ на: комментарий от YesSSS

Что имеем: система с запущенными определенными системами.
Что должны иметь в итоге: программное средство, реагирующее определенном образом на некорректное завершение заданных процессов, и системных и прикладных.

Программа поделила на нуль - сигнализируем о том, что процесс с таким-то pid'ом, запущенная от такого-то пользователя завалилась в таком-то потоке.

Что надо на текущем этапе: понять каким образом и на каком уровне отлавливать сообщения/сигналы о некорректном завершении процессов и прочих ошибках.

Что надо на следующем этапе: из этих сообщений/событий научиться вытаскивать такую информацию, как pid'ы, идентификаторы потоков, типы ошибок.

Только поняв все это уже приступать к реализации.

Еще попутно, был бы благодарен за подсказку, какую-литературу почитать по Linux-API, типы сообщений ОС и межпроцессного взаимодействия.

dogmeat-fall
() автор топика
Ответ на: комментарий от dogmeat-fall

Когда приложение делит на ноль/лезет в неалоцированную память и т.д. к нему приходит сигнал(man 7 signal) от ОС. Перехватить и обработать его может само приложение, ОС(или твой модуль ядра) и, на сколько я понимаю, сторонее приложение типа gdb(не интересовался как он это делает). Номер сигнала говорит о типе ошибки, pid/tid однозначно обозначают процесс/поток. Все это можно получить например написав модуль ядра или использовав gdb. С gdb будет проще и результат будет лучше(узнаешь не только о том, что приложение поделило на ноль, но и где оно это сделало и чем были заняты в этот момент другие нити). Отсюда и вопрос чем тебя так не устраивает этот вариант.

YesSSS ★★★
()
Ответ на: комментарий от YesSSS

Все системные процессы запускать через дебаггер?

dogmeat-fall
() автор топика
Ответ на: комментарий от YesSSS

Знать в каком месте кода оно завалилось не нужно.

dogmeat-fall
() автор топика

Посмотри еще SystemTap и примеры отслеживания сигналов

http://sourceware.org/systemtap/examples/keyword-index.html#SIGNALS

# process/sigkill.stp - Track SIGKILL Signals keywords: SIGNALS

The script traces any SIGKILL signals. When that SIGKILL signal is sent to a process, the script prints out the signal name, the destination executable and process ID, the executable name user ID that sent the signal.

Я эту штуку не применял, но судя по примерам это то, что тебе нужно.

YesSSS ★★★
()

Может, audit это умеет?

const86 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.