Suivi d'un processus

Kevin Denis , dans le message
<slrnm7reje.6cn.kevin@slackwall.local.tux>, a écrit :

j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.

Tu es sûr que le C est le plus adapté pour cet usage ? Quel volume de logs ?
Quel genre de parsing ?

En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.

J'espère bien que le programme ne se termine pas avec un signal quand il
rencontre une erreur de syntaxe, donc si, le code de retour t'aide, pour peu
que tu l'utilises correctement, puisqu'il distingue bien un code de retour
normal (de succès ou d'erreur mais normal) d'un signal.

Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?

Pour commencer, je pense que tu devrais lui faire produire un core. Tu peux
vérifier si ça fonctionne bien en le faisant crasher exprès avec un SIGQUIT.

Il y a bien des solutions plus lourdes, strace et valgrind évidemment, mais
je conseille de commencer par l'élémentaire.

Le 02 Dec 2014 09:30:19 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :

Bonjour,

j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.

En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.

Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?

Bonsoir,

ulimit -u unlimited et un script de lancement devrait pouvoir
détecter le segfault.

Sinon, si tu as les mains sur les sources, installe un gestionnaire
de signaux sur SIGSEGV qui renvoie un code d'erreur spécifique.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

Le 02/12/2014 10:30, Kevin Denis a écrit :

Bonjour,

j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.

En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.

Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?

Merci

Si tu peux compiler/linker facilement à partir du source le plus simple
est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec
des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut
détecter l'endroit "où ça plante" quand on n'a pas d'idée.

Au fur et à mesure tu peux ajouter/enlever des sorties de messages
d'erreur sur un log. C'est *antique*, mais ça doit encore fonctionner.
L'idée est d'avoir un cas de crash précis et de l'exploiter jusqu'à plus
soif. Mais dans les applis, si le programmeur a de mauvaises habitudes,
il peut rester plusieurs cas de crash différents, d'où l'idée d'en
traiter un seul à la fois.
cdt

Bonjourn


MAIxxx wrote:

Si tu peux compiler/linker facilement à partir du source le plus simple
> est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec
des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut
détecter l'endroit "où ça plante" quand on n'a pas d'idée.

Dans l'hypothèse ou l'auteur original de cet article possède les sources, je
suggèrerais plutôt une compilation avec ajout des informations de débogage
(option -g pour gcc ou g++) et l'usage d'un débogueur (j'aime bien ddd qui
est une surcouche graphique de gdb).

Je crois que c'est aussi possible sur un code pour lequel on ne possède pas
la source, voire sur le "core" qu'il génère lors de son plantage. Mais là,
ça sort de ma compétence.

Cordialement

Dominique

Le 03-12-2014, Dominique MICOLLET <anonymous@invalid.fr> a écrit :

Dans l'hypothèse ou l'auteur original de cet article possède les sources, je

En fait, non. C'est du vieux code "legacy".

J'ai testé un enrobage avec python. Grosso modo, ça ressemble à ça:
def go(shell_command):
debug_print("[.] Launching ... "+shell_command)
proc = Popen(shell_command, shell=True, stdout=PIPE, stderr=PIPE)
if proc.returncode == 139 or proc.returncode == -11:
crash(shell_command)

Ca semble bon pour attraper l'erreur.
--
Kevin