Journalisation des démons sous Linux

Question

J'ai donc un démon qui tourne sur un système Linux, et je veux avoir un enregistrement de ses activités : un journal. La question est de savoir quelle est la "meilleure" façon d'y parvenir.

Ma première idée est d'ouvrir simplement un fichier et d'y écrire.

FILE* log = fopen("logfile.log", "w");
/* daemon works...needs to write to log */
fprintf(log, "foo%s\n", (char*)bar);
/* ...all done, close the file */
fclose(log);

Y a-t-il quelque chose d'intrinsèquement mauvais dans le fait d'enregistrer de cette manière ? Existe-t-il un meilleur moyen, tel qu'un cadre intégré à Linux ?

Answer 1

Unix dispose depuis longtemps d'un cadre de journalisation spécial appelé syslog . Tapez dans votre shell

man 3 syslog

et vous obtiendrez l'aide pour l'interface C.

Certains exemples

#include <stdio.h>
#include <unistd.h>
#include <syslog.h>

int main(void) {

 openlog("slog", LOG_PID|LOG_CONS, LOG_USER);
 syslog(LOG_INFO, "A different kind of Hello world ... ");
 closelog();

 return 0;
}

Answer 2

Este sera probablement un était une course de chevaux, mais oui, la fonction syslog qui existe dans la plupart, sinon tous les dérivés d'Un*x, est la meilleure façon de procéder. Il n'y a rien de mal à enregistrer dans un fichier, mais cela vous laisse un certain nombre de tâches sur les bras :

• Existe-t-il un système de fichiers à votre emplacement d'enregistrement pour sauvegarder le fichier ?
• Qu'en est-il de la mise en mémoire tampon (pour les performances) par rapport à la vidange (pour que les journaux soient écrits avant que le système ne tombe en panne) ?
• si votre démon fonctionne pendant une longue période, que faites-vous du fichier journal qui ne cesse de croître.

Syslog s'occupe de tout cela, et plus encore, pour vous. L'API est similaire au clan printf, vous ne devriez donc pas avoir de problèmes pour adapter votre code.

Answer 3

Un autre avantage de syslog dans les installations plus importantes (ou plus soucieuses de la sécurité) : Le démon syslog peut être configuré pour envoyer les journaux à un autre serveur afin qu'ils y soient enregistrés au lieu (ou en plus) du système de fichiers local.

Il est beaucoup plus pratique d'avoir tous les journaux de votre batterie de serveurs au même endroit plutôt que de devoir les lire séparément sur chaque machine, en particulier lorsque vous essayez de corréler les événements d'un serveur avec ceux d'un autre. Et lorsque l'un d'eux est piraté, vous ne pouvez plus faire confiance à ses journaux... mais si le serveur de journaux est resté sécurisé, vous savez que rien n'aura été supprimé de ses journaux, et que toute trace de l'intrusion sera donc intacte.

Answer 4

Je crache beaucoup de messages de démon vers daemon.info et daemon.debug lorsque je fais des tests unitaires. Une ligne dans votre syslog.conf peut placer ces messages dans le fichier de votre choix.

http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/040/4036/4036s1.html contient une meilleure explication de l'API C que la page de manuel, imo.

Answer 5

Syslog est une bonne option, mais vous pouvez également envisager log4c. Les frameworks log4[something] fonctionnent bien dans leurs implémentations Java et Perl, et vous permettent - à partir d'un fichier de configuration - de choisir de journaliser soit vers syslog, soit vers la console, soit vers des fichiers plats, soit vers des rédacteurs de journaux définis par l'utilisateur. Vous pouvez définir des contextes de journalisation spécifiques pour chacun de vos modules, et faire en sorte que chaque contexte soit journalisé à un niveau différent, tel que défini par votre configuration. Vous pouvez définir des contextes de journalisation spécifiques pour chacun de vos modules, et faire en sorte que chaque contexte enregistre à un niveau différent défini par votre configuration (trace, debug, info, warn, error, critical), et faire en sorte que votre démon relise ce fichier de configuration à la volée en piégeant un signal, ce qui vous permet de manipuler les niveaux de journalisation sur un serveur en cours de fonctionnement.