Petits tracas dans l'informatique
“It’s not a bug, it’s a feature”. Cette phrase bien connue dans le monde informatique peut faire rire, ou pleurer… Cette dernière expérience m’est arrivée pas plus tard qu’hier.
Contexte : un ordinateur démarre connecté au réseau. Ses services se lancent très rapidement tandis que son interface réseau paramétrée par DHCP ne se trouve en nominal que bien après. Cependant, certains des services utilisent le réseau et cherchent à résoudre des noms avant d’avoir la connectivité.
Lorsque le service fait appel à la fonction gethostbyname, le fichier /etc/resolv.conf est lu pour déterminer les DNS à contacter pour obtenir la résolution des noms. Problème : ce fichier n’est lu qu’une fois, et ses données sont conservées en mémoire indépendamment du fait que le fichier /etc/resolv.conf puisse être mis à jour par la suite par le client dhcp.
Vous imaginez bien que c’est assez gênant de se retrouver sans résolution de nom dans un daemon qui doit a priori communiquer avec le monde extérieur. Je considère ceci comme un bug de la libc et pour plusieurs raisons :
* L’interface offerte au niveau de gethostbyname est une abstraction qui permet d’aller chercher la résolution de nom par différents moyens à disposition du système. Que le système aille piocher dans un fichier, sur un serveur avec un protocole spécifique, le client n’en a cure car il demande juste le service. * D’un point de vue architecture, le fait que la bibliothèque charge le contenu du fichier /etc/resolv.conf est une accélération par l’utilisation d’un cache. MAiS un cache doit avoir une politique de gestion d’obsolescence de ses données, et visiblement la glibc n’en a pas pour ce service de résolution.
Alors bien sur, “man resolver” indique clairement que le fichier n’est lu que lors du premier appel, mais le fait de documenter un bug ne suffit pas à le faire disparaître.
Je ne suis pas le seul à avoir rencontré ce problème. Des tickets de bugs ont été remontés au mainteneur de la glibc, le bien connu Ulrich Drepper, surtout connu pour ses rapports très tendus (à la Torvalds, diront certains) avec les personnes avec lesquelles il n’est pas d’accord. Sur ce point, M. Drepper n’est justement pas d’accord. Sa réponse est aussi simple que fausse :
bq[en]. nscd is required to make changes work. Period. I won’t add code into the stub resolver to check the file every time. This is far too slow. We have a perfectly fine solution, so use it.
bq[en]. I’ve been arguing to change the default to use nscd by default for a long time. In fact, we should completely remove the option to not use nscd.
Franchement, rajouter une dépendance pour ne pas avoir à gérer proprement un cache, ça me dépasse. Au final, c’est à l’application d’avoir à descendre dans les méandres de la résolution de nom du système pour obtenir que le service soit rendu correctement. Dans le cas de notre application, daemon embarqué sur un système complêtement sous notre maîtrise, c’est encore acceptable, mais il faut voir que pour toutes les applications dont la durée de vie est susceptible de dépasser le temps de connexion à un réseau (PC avec capacité de veille sur disque), celà signifie une danse avec les appels systèmes pour se remette à jour par soi-même. Un beau gaspillage de ressource…
Heureusement, la glibc est un projet libre et permet la dérivation. eglibc en est l’exemple. Debian et Ubuntu ont déjà basculé sur cette nouvelle libc, surement parce que leurs propositions de patch sont mieux acceptées upstream, ce qui doit rester l’avantage du logiciel libre.
No comments