Bonjour Niloo, et merci de te pencher sur ce problème !
J’ai trouvé plus bourrin comme solution : stopper la journalisation tout court 
Ouais bon, OK, c’est super moyen : je vais bien sûr tester l’arrêt de la journalisation de pdns.
Des extraits de log, en voilà : il faut juste s’imaginer chaque séquence répétée sur des kilomètres…
/var/log/syslog
Mar 16 12:54:39 tjener slapd[3537]: daemon: shutdown requested and initiated.
Mar 16 12:54:39 tjener slapd[3537]: slapd shutdown: waiting for 0 threads to terminate
Mar 16 12:54:17 tjener pdns[18984]: Creating backend connection for TCP
Mar 16 12:54:17 tjener pdns[18984]: About to create 3 backend threads for UDP
Mar 16 12:54:17 tjener pdns[18982]: Listening on controlsocket in '/var/run/pdns.controlsocket'
Mar 16 12:54:17 tjener pdns[18984]: Guardian is launching an instance
Mar 16 12:54:17 tjener pdns[18984]: This is a guarded instance of pdns
Mar 16 12:54:17 tjener pdns[18984]: UDP server bound to 127.0.0.1:53
Mar 16 12:54:17 tjener pdns[18984]: UDP server bound to 192.168.1.58:53
Mar 16 12:54:17 tjener pdns[18984]: UDP server bound to 192.168.0.254:53
Mar 16 12:54:17 tjener pdns[18984]: TCP server bound to 127.0.0.1:53
Mar 16 12:54:41 tjener slapd[3537]: slapd stopped.
Mar 16 12:54:17 tjener pdns[18984]: TCP server bound to 192.168.1.58:53
Mar 16 12:54:17 tjener pdns[18984]: TCP server bound to 192.168.0.254:53
Mar 16 12:54:17 tjener pdns[18984]: PowerDNS 2.9.21.2 (C) 2001-2008 PowerDNS.COM BV (Nov 25 2008, 22:40:57, gcc 4.3.2) starting up
Mar 16 12:54:17 tjener pdns[18984]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
/var/log/messages
Mar 16 12:54:17 tjener pdns[18984]: About to create 3 backend threads for UDP
Mar 16 12:54:17 tjener pdns[18982]: Listening on controlsocket in '/var/run/pdns.controlsocket'
Mar 16 12:54:17 tjener pdns[18984]: This is a guarded instance of pdns
Mar 16 12:54:17 tjener pdns[18984]: PowerDNS 2.9.21.2 (C) 2001-2008 PowerDNS.COM BV (Nov 25 2008, 22:40:57, gcc 4.3.2) starting up
Mar 16 12:54:17 tjener pdns[18984]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
/var/log/mail.log
Mar 16 12:07:35 tjener imapd-ssl: Connection, ip=[::ffff:192.168.1.58]
Mar 16 12:07:35 tjener imapd-ssl: LOGOUT, ip=[::ffff:192.168.1.58], rcvd=11, sent=309Le remplissage de ce fichier n’avait pas commencé lors du dernier test…
/var/log/auth.log
Mar 16 12:05:01 tjener CRON[7406]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 16 12:05:01 tjener CRON[7408]: pam_unix(cron:session): session closed for user root
Mar 16 12:05:02 tjener CRON[7407]: pam_unix(cron:session): session closed for user munin
Mar 16 12:05:01 tjener CRON[7408]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 16 12:10:01 tjener CRON[8572]: pam_unix(cron:session): session closed for user root
Mar 16 12:10:01 tjener CRON[8571]: pam_unix(cron:session): session opened for user munin by (uid=0)
Mar 16 12:09:01 tjener CRON[8338]: pam_unix(cron:session): session closed for user root
Mar 16 12:10:02 tjener CRON[8571]: pam_unix(cron:session): session closed for user munin
Mar 16 12:09:01 tjener CRON[8338]: pam_unix(cron:session): session opened for user root by (uid=0)Le remplissage de ce fichier n’avait pas commencé lors du dernier test…
Euh, par contre, je pige pas : jusque-là, je me contentais de tester la manip décrite dans le premier post (arrêt de pdns, redémarrage de rsyslog), puis je constatais à nouveau le problème après avoir redémarré pdns. Curieux de voir si ce n’était pas aussi (plutôt ?) lié à slapd, dans un nouveau test j’ai arrêté slapd avant de redémarrer rsyslog. En redémarrant slapd, le problème ne se pose plus.
Je viens de tester ceci :
[code]# /etc/init.d/slapd restart
/etc/init.d/pdns restart
/etc/init.d/rsyslog restart[/code]
Et… rien, tout fonctionne à merveille.
Entre temps, j’ai “juste” modifié à la main /etc/resolv.conf, qui contenait ceci :
[code]# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
DO NOT EDIT THIS FILE BY HAND – YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search intern[/code]… pas très pratique pour se connecter à Internet : j’y ai donc inséré, avant la première déclaratoin “nameserver” la ligne “nameserver 192.168.1.1”. Je vais tester le retrait de la ligne, histoire de voir si ça change vraiment quelque chose.
Voilà, si tu as besoin d’autre chose pour te faire une idée, je te le donnerais avec grand plaisir !
Ouais, je pars un peu dans tous les sens… Disons que l’administration d’un serveur Linux n’est clairement pas mon métier premier, et que j’essaie de comprendre les concepts et interactions sur le tas. C’est moins efficace que des cours en classe, on est d’accord 
EDIT :
Après test de modification de /etc/resolv.conf, il est CLAIR que ça change quelque chose. Si j’enlève la ligne désignant la passerelle, ça repart comme en 14 : bombardement de log assuré. En revanche, je remets la ligne, je redémarre rsyslog, et tout va bien, le soleil brille et les oiseaux chantent… ah non, ça c’est dehors… tout va bien, les journaux se remplissent normalement.
Je ne sais pas pourquoi la passerelle n’était pas indiquée de base dans le fichier (pas très pratique pour les mises à jour de paquets, ça), ni pourquoi slapd/pdns/rsyslog (rayer les mentions inutiles) s’affolent à ce point dans ce cas. Mais ça semble déjà être un grand pas vers une solution, non ?
