[RESOLU] bind9 en chroot perd le multithread?

Voilà, j’ai un core 2 duo, et quand je regarde le log de bind9 en non chroot et en chroot

Je vois d’abord 2 CPU et 2 threads. C’est pas normalement 1 CPU et 2 threads?

Jan 26 18:51:09 server-dns named[2684]: starting BIND 9.5.0-P2 Jan 26 18:51:09 server-dns named[2684]: found 2 CPUs, using 2 worker threads Jan 26 18:51:09 server-dns named[2684]: loading configuration from '/etc/bind/named.conf'

et en chroot, j’ai 1 CPU et 1 thread.
C’est bizarre tout ca non?

Jan 26 18:52:38 server-dns named[2704]: starting BIND 9.5.0-P2 -u bind -t /var/lib/named Jan 26 18:52:38 server-dns named[2704]: found 1 CPU, using 1 worker thread Jan 26 18:52:38 server-dns named[2704]: loading configuration from '/etc/bind/named.conf'

Quelqu’un a le même problème et comment on explique ca?

Tout d’abord, un CPU est une unité de traitement, pas un processeur physique. Donc 1 coeur = 1 CPU. Ensuite, faut voir comment BIND détecte le nombre de CPU. Si c’est en lisant /proc/cpuinfo, alors il faut que /proc soit monté aussi dans le répertoire qui sert de racine au chroot (ou bien y créer un proc/cpuinfo bidon, mais c’est de la triche). Si c’est juste le nombre de threads qui t’intéresse, tu peux le forcer avec l’option -n 2 dans la ligne de commande, qui peut être ajoutée dans la variable OPTIONS définie dans /etc/defaults/bind9.

oui effectivement, en copiant le fichier cpuinfo dans le chroot ca marche.
Je comprends mieux, merci
Par contre ca marche pas avec un ln -s ?
J’avais fait un ln -s /proc/cpuinfo /var/lib/named/proc/cpuinfo
mais ca reste à 1 cpu

En gros là ça dit que /var/lib/named/proc/cpuinfo, qui devient /proc/cpuinfo un fois chrooté, pointe vers /proc/cpuinfo par rapport à la racine du chroot. Ça l'aide vachement...

En gros là ça dit que /var/lib/named/proc/cpuinfo, qui devient /proc/cpuinfo un fois chrooté, pointe vers /proc/cpuinfo par rapport à la racine du chroot. Ça l’aide vachement…

c’etait pas une question
j’avais fait

ca marche pas, alors qu’un cp ca marche

Pas une question ? Pourtant il y avait un point d’interrogation.
Je sais qu’un lien symbolique ne marche pas, et j’ai expliqué pourquoi.

oui j’ai mal écrit, trop vite, le point d’interrogation ne devrait pas être la.

la racine de mon chroot sur c’est /var/lib/named/

et si tu veux dire qu’il faut que je fasse plutot ca :

c’est pareil.

J’avais bien compris.

[quote=“LastLemming”]et si tu veux dire qu’il faut que je fasse plutot ca :

Non, je veux dire que tu auras beau retourner la question dans tous les sens, un lien symbolique ne permet pas d’accéder à un fichier ou répertoire qui est en-dehors du chroot. Un lien symbolique, c’est juste du texte qui indique la position relative (par rapport au répertoire du lien, si ne commence pas par /) ou absolue (par rapport à la racine du chroot, si commence par /) de la cible.

bref tu veux dire qu’il est impossible de faire un ln vers une cible qui est hors du chroot?
oui, j’ai du tout melangé quand j’avais fait un chroot de apache et qu’il fallait faire un ln sur le socket mysql, en faite ça du être en sens inverse, demander à mysql d’écrire sur le socket qui est dans le chroot d’apache.

Tu peux éventuellement faire un montage en bind (va voir le T&A sur le chroot). Mais ici, je ne vois pas l’inconvénient de monter /proc dans le chroot.

Je ne sais pas ce que c’est le T&A

:slightly_smiling: Trucs et Astuces, section du forum…http://forum.debian-fr.org/viewtopic.php?f=8&t=14673

ok dans le /etc/fstab

voila c’est bon aussi

Jan 27 03:32:07 server-dns named[2040]: starting BIND 9.5.0-P2 -u bind -t /var/lib/named Jan 27 03:32:07 server-dns named[2040]: found 2 CPUs, using 2 worker threads Jan 27 03:32:07 server-dns named[2040]: loading configuration from '/etc/bind/named.conf'

quels sont impacts de cette ligne au niveau occupation cpu, memoire, utilisation I/O ?
n’est-ce pas trop risqué d’avoir l’acces à autant d’info de l’ensemble de /proc dans le chroot ?

Ces infos ne sont exploitables que si tu es root, et si tu es root, tu peux monter /proc…