les comportements erratiques de syslog-ng
Par gblanc le mercredi, décembre 10 2008, 19:10 - informatique - Lien permanent
* un fichier sans ligne "destination remote" implique une impossibilité de démarrer syslog-ng (avec une erreur franchement pas belle, ça râle)
* un fichier avec un "destination remote { };" garde les logs uniquement en local
* un kill -HUP envoyé sur un syslog-ng relit le fichier de conf et le prend en compte (sans changer le PID, mais un changement de filtre en plus permissif montre bien que ça été pris en compte)
Soit un fichier avec un "destination remote" avec ou sans IP à l'intérieur permet de démarrer le syslog-ng sans problème. On enlève la ligne "destination remote". On envoie un -HUP. Question : que se passe-t-il ? Eh bien rien du tout. Encore un bug non détecté... (pour le cas où l'on démarre le démon à la main, ce qui en l'occurrence n'arrivait qu'au démarrage, et pour un fichier sans adresse IP de serveur distant : il fallait deviner que ça ne voulait pas démarrer sans !)
Commentaires
Tu dis toi-même que ton fichier de configuration sans "destination remote" ne permet pas de le démarrer. La configuration est donc incorrecte.
Envoyer SIGHUP à syslog-ng change sa configuration, certes, mais uniquement si la nouvelle configuration est correcte. Si elle ne l'est pas (par exemple parce que "destination remote" a été enlevé), alors l'exécution continue comme si de rien n'était, avec les paramètres chargés précédemment.
Je ne trouve pas cela erratique, mais logique. Cela dit, il est probable que tu retrouves des messages d'erreur expliquant pourquoi il n'a pas chargé la nouvelle configuration dans le log (tel que précédemment configuré bien sûr).
Salut Sam ! :) Tu as raté un épisode : le fichier modifié mais non valide est bien pris en compte. Test fait en changeant les niveaux de filtres de log. Sinon, ça aurait été trop simple : tout aurait buggé depuis longtemps déjà... (il est possible de changer via nos interfaces divers paramètres, pas seulement les adresses IPs distantes)