Fork me on GitHub

About

Vous êtes sur le weblog de JN Avila

Pages

Add some pages here, or start a new chapter.

Tag Cloud

Archives

Categories

Links

Alpinux
Aroblog
Hayabousa
Le blog de Raphy Stoller
le blog de Belu
stellamatutina
Da BOop
JS Zone
Irresponsable !
Blablog
Mistress Doom Bazar
Le monde de Cornelius
Why-Note

Search

Latest Comments

Nathalia (Fin de vacances): Tiens, tu blogues perso maintenant ?
DBF (Mes dernières lec…): Plus léger et en phase avec l’actu www.decitre.fr/livres/star -wars-l.. Joyeux Noël, JNA.
JN (Real humans and c…): C’est en anglais parce que je voulais en faire une réponse à l’article initial.
Frérot (Real humans and c…): Waowww, You’ve gone deep into the episodes… By the way, like you, I was kind of fond of “Real Human…
Cami (Les joies de l'in…): Bonjour! Si vous êtes intéressés de traduire logiciels pour Internet, pour PC, pour mobiles ou tout a…
Mathieu (Pas sérieux): …. je vois passer les avions avec bandeaux publicitaires au-dessus des plages depuis la fenêtre de mo…

Stuff

Powered by PivotX - 2.3.3 
XML: RSS Feed 
XML: Atom Feed 

« Ah, les signatures de… | Home | Dommage »

Petits tracas dans l'informatique

Saturday 13 February 2010 at 9:50 pm. Used tags:

“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

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Del.icio.us
  • Digg
  • Facebook
  • Google
  • LinkedIn
  • StumbleUpon
  • Tumblr
  • Twitter




(optional field)
(optional field)
Remember personal info?
Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.