Discussion :

[Mayhem555]

Bonjour.

Je poste sur ce forum parce que je ne voit pas dans quel autre je pourrais mettre ce thread.

Je développe actuellement (en C sur une Linux Fedora 9) un petit utilitaire de monitoring permettant de lancer/stopper des daemons sur ma machine. Ces démons, ils sont déjà programmés et finalisés, et je les lances/stop grâce à des appels à des scripts bash.

Bon c'est bien beau tout ça, mais ces daemons tournent en tâche de fond, et observent le réseau (uniquement certains paquets), analysent le contenu (parsing) puis écrivent le résultat dans des fichiers log générés automatiquement.

Ce que je voudrais que fasse mon outil, c'est de récupérer ces fichiers log, de compter les lignes remplies à chaque intervalle de temps (par exemple chaque seconde), et de tracer graphiquement le nombre de ligne remplies dans mon outil. Avec le graphe qui se déplace chaque seconde vers la gauche pour permettre le traçage d'une nouvelle donnée.
En pratique, je voudrais pouvoir avoir quelque chose de comparable au graphe du moniteur d'activité du CPU ou bien d'occupation de la mémoire vive (présents aussi bien sur Linux que sur Windows).

Je n'ai absolument aucune idée de comment faire la chose. Mon application est programmée avec GTK+, et je ne vois pas du tout par quel bout prendre ce probleme...

Votre aide serait grandement appréciée !

Merci.

[Obsidian]

Hors-Topic : J'ai été déçu par Fedora 9. Autant, j'ai adoré le système jusqu'à sa version 8, autant je n'ai que des ennuis avec la 9.

Ton problème a deux pans bien distincts : récupérer les infos, d'une part, et manipuler l'interface graphique, de l'autre.

Pour le premier cas, ça va dépendre en grande partie de la taille de tes logs. Si je ne me trompe pas, il n'y a pas de dispositif sous Unix qui permettent d'être prévenu d'un mouvement sur un fichier ouvert, contrairement à un socket, parce qu'une lecture sur un fichier ordinaire qui touche à sa fin provoque un EOF et pas une mise en attente (appel bloquant). La dernière fois que j'avais vérifié, « tail -f » faisait du polling pour parvenir à ses fins.

Toujours est-il que, pour compter le nombre de lignes d'un fichier texte, il te faut le parcourir en entier à chaque fois et compter les '\n'.

Tu peux essayer d'optimiser la chose en conservant le fichier ouvert en lecture, en surveillant la fin de fichier à chaque appel et vérifiant si de nouvelles lignes ont été ajoutées, et en ne comptabilisant que celles-ci le cas échéant, mais cela a quand même plusieurs inconviénients : si ton fichier de log est supprimé, ton programme ne le saura pas (le fichier continuera d'exister en zombie sur le disque, sans être référencé, et ne disparaîtra réellement qu'à la fermeture de ton code). Même chose s'il est renommé par un truc comme logrotate, mais là, le problème est le même pour tout le monde, et ce dernier permet d'envoyer des signaux au processus concerné si besoin.

Du côté de GTK, maintenant, il faut regarder le manuel de référence, en ligne ou téléchargeable. Les primitives graphiques de bas niveau sont prises en charge, me semble-t-il, par GDK en particulier.

http://www.gtk.org/
http://www.gtk.org/documentation.html
http://library.gnome.org/devel/gdk/stable/
http://library.gnome.org/devel/gdk/s...rimitives.html

[souviron34]

Pour le premier cas, ça va dépendre en grande partie de la taille de tes logs. Si je ne me trompe pas, il n'y a pas de dispositif sous Unix qui permettent d'être prévenu d'un mouvement sur un fichier ouvert, contrairement à un socket, parce qu'une lecture sur un fichier ordinaire qui touche à sa fin provoque un EOF et pas une mise en attente (appel bloquant). La dernière fois que j'avais vérifié, « tail -f » faisait du polling pour parvenir à ses fins.

Il y a un moyen assez efficace aussi..

Un timer qui vérifie régulièrement la date de modification du fichier via la structure et fonction stat...

(élément st_mtime de la structure, à comparer avec la date sauvegardée)