lo tomàs avança

“La vida es muy peligrosa. No por las personas que hacen el mal, sino por las que se sientan a ver lo que pasa.”

Albert Einstein

Després d’investigar i recompilar alguns kernels jugant amb parches he trobat la solució al problema.

Un resum del problema podria ser:

[root@compute-0-0 root]# /etc/init.d/gmond status
gmond dead but subsys locked

Tenia 2 possibles aproximacions, investigar sobre els pegats del nucli per donar-li suport nptl o investigar l’ús de les llibreries estandards que feia Ganglia. Per Murphy, primer vaig anar a la del nucli, gastant 3 dies sense resultats. I avui, per desesperació he anat cap a la de les llibreries.

Observant les llibreries compartides que utilitza gmond (amb greceptor és el mateix cas) podem veure:

[root@compute-0-0 root]# ldd /usr/sbin/gmond
libdl.so.2 => /lib/libdl.so.2 (0×40020000)
libresolv.so.2 => /lib/libresolv.so.2 (0×40023000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40035000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4004a000)
libc.so.6 => /lib/tls/libc.so.6 (0x4005a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Aquí veiem que utilitza les llibreries situades a /lib/tls, que són les llibreries compilades amb suport per NPTL, pro com el nucli no disposa d’aquest suport es penja a l’hora de crear els threads (LinuxThreads del vanilla versus NPTL threads de la llibreria TLS).

Primera solució a lo cutre:

# mv /lib/tls /lib/tls-mala

Doncs sorprenentment ha funcionat. Després de realitzar aquest canvi tornem a fer ldd a veure que trobem:

[root@compute-0-0 root]# ldd /usr/sbin/gmond
libdl.so.2 => /lib/libdl.so.2 (0×40020000)
libresolv.so.2 => /lib/libresolv.so.2 (0×40023000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40035000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4004a000)
libc.so.6 => /lib/i686/libc.so.6 (0x4009b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Voilà! Ara, automàticament agafa unes noves llibreries (les estandard) sense suport per NPTL, i inmediatament podem comprobar que ja funciona bé:

[root@compute-0-0 root]# /etc/init.d/gmond restart
Shutting down GANGLIA gmond: [FAILED]
Starting GANGLIA gmond: [ OK ]
[root@compute-0-0 root]# /etc/init.d/gmond status
gmond (pid 2803 2802 2801) is running…

Des del monitor web del Ganglia igualment podem veure que el sistema ha detectat que el compute-0-0 està actiu. Visca!

Només quedaran 2 passos:

1. Comunicar-ho a la llista de Rocks

2. Introduir-ho dintre el procediment general d’instalació del clúster.

Avui, buscant al llibre “Linux 6a Edicion” he trobat un subcapitul anomenat “Uso de ldd para localizar las bibliotecas compartidas necesarias”, que estava dintre el capitul “Compatibilidad entre bibliotecas”, que es un dels problemes que tinc. Aqui reproduire algunes de les parts mes importants.

Per examinar les biblioteques compartides que necessita un programa ho podem fer de la seguent forma:

# ldd /usr/bin/vi
libncurses.so.5 => /lib/libncurses.so.5 (0×40022000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0×40063000)
libperl.so.1 => /usr/lib/libperl.so.1 (0×40069000)
libutil.so.1 => /lib/libutil.so.1 (0×40168000)
libc.so.6 => /lib/libc.so.6 (0x4016b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4029a000)
libm.so.6 => /lib/libm.so.6 (0x402ec000)
libdl.so.2 => /lib/libdl.so.2 (0x4030e000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40311000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0×40326000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Aqui tenim una mostra de totes les llibreries que usa el vi.

“Si la biblioteca que falta tiene un numero de version principal diferente, simplemente encuentre el paquete que ofrece la version de biblioteca que necesita, e instalelo. Si los numeros de la version principal son diferentes, el restante software de su sistema no resultara afectado por la adicion de otra biblioteca, aunque se llame igual.”

Aixo es el que em passa amb la llibreria libc, que tinc instalades 2 versions amb diferent implementacio.

“Otra solucion es crear un enlace simbolico para el nombre de la biblioteca compartida que necesita. Enlacelo a una biblioteca ya existente en su sistema y confie en que la biblioteca sea compatible. Esto es posible que funcione en algunas circunstancias, dependiendo de cuanto se usa esa biblioteca y a que subrutinas hace referencia el programa. Sin embargo, esta es una medida para salir del paso, y deberia usarse solo cuando se sabe con seguridad que las versiones en cuestion son compatibles para los propositos del programa.”

Seguint a la pagina 422 explica el mecanisme que utilitza Linux per carregar els programes.

Mes endavant, i canviant de tema, hi ha un capitol anomenat “Consultas avanzadas sobre paquetes RPM” amb un subcapitol que diu “Extraccion de los contenidos de un paquete rpm (rpm2cpio)”, que explica com treure els fitxers d’un paquet RPM.

# rpm2cpio kernel-2.4.22-1.2174.nptl.src.rpm | cpio -ivd
Llistat dels fitxers extrets

Pozi, realment funciona be, fa exactament el que buscava fer. UOLE! Dintre contenia un tots els arxius .patch i el codi font del kernel 2.4.22, a part d’alguns scripts en awk que suposo que son per instalar tots els parches.

He d’acabar de llegir aquest capitol, ja que explica moltes coses que no sabia i necessito.

Be, tornant a la feina, novetats. He obert el kernel RHEL de la Rocks, el kernel-2.4.21-15.0.3.EL.src.rpm, i es mes intuitiu del que em pensava. Dintre hi ha el fitxer kernel-2.3.spec, que es l’encarregat de construir tot el paquet, agafant com a base el vanilla kernel que porta (un linux-2.4.21.tar.bz2) i despres li aplica tots els parches que troba oportuns (clarament especificats al .spec). Molt ben pensat, si senyor.

Despres de l’analisi del .spec he trobat el que buscava. Per a l’arquitectura x86 hi ha 2 pegats de l’NPTL:

1. linux-2.4.20-o1-nptl.patch

2. linux-2.4.21-nptl-network.patch
3. I por si las moscas tb apunto el linux-2.4.21-tux.patch

Probare d’aplicar-los al kernel 2.4.22, a veure que passa. A la 2.4.22 directament no l’he pogut aplicar, pq em donava un munt d’errors, ja que els parches no estaven preparats per a aplicar-se directament.

Seguint el .spec original he vist que el parche de l’nptl (el o1) era el 4t en aplicar-se sobre un kernel 2.4.21, de forma que he reproduit el procediment i sembla que ha funcionat. Ara ja l’estic compilant com si fos un kernel Rocks (vigilar pq fa preguntes sobre opcions noves del kernel). D’aqui 30 minuts sabrem mes (aixo es com preparar un pastis xD).

De moment poso els pegats i l’ordre en que els he posat:

1. linux-2.4.21-dailybk.patch

2. linux-2.4.21-select-upstream-bits.patch
3. linux-2.4.21-selected-ac-bits.patch

Aquesta setmana, a part de fer la previa de Periferics i reinstalar GNU/Linux tambe he tornat amb el projecte, tal i com tenia previst. Aquesta setmana i despres d’acabar tota la feina que tenia que fer per fi he pogut quedar amb la gran ajuda per al projecte, el David.

Doncs aixo, vaig quedar amb el tecnic del departament que m’ajuda amb el projecte (acabo de veure que ha fet traduccions de KDE), i li vaig explicar els dos problemes que tenia:

1. Els processos de prova del Linpack no migraven cap a un dels 2 ordenadors del cluster.

2. Ganglia no funciona, quan faig un /etc/init.d/gmond status em diu “gmond dead but subsys locked”.

Doncs be, nem per parts:

1. Per aquesta part va passar algo molt extrany, pero alhora molt normal. Quan va venir i li vaig explicar lo que tenia al seguir el procediment d’aqui. Un fitxer machines amb el nom dels 2 nodes que fa servir el linpack per computar:

   # vi machines
   compute-0-0
   compute-0-1

   A part, el fitxer de configuracio de l’HPL baixat de aqui.
   Lo altre ja es magia. Despres d’haver-ho intentat durant un munt de temps, ahir, i sense rao aparent, tot va funcionar. Murphy, oh, Murphy.

   Com a possible solucio a coses magiques he fet un test de memoria a la RAM de l’ordinador en questio, pero no ha donat cap error.

   Conclusio: A tornar a fer proves, o sigui que estare molt solet per aqui.

2. Be, el segon problema ja es mes peliagut. El David va estar-ho mirant, amb un munt d’eines, algunes conegudes pero que el seu nom me provoca panic (lease gdm) i altres que ni recordo el nom que no coneixia.

   Finalment vam arribar a 2 conclusions:

   • Per algun lloc, al fer el /etc/init.d/gmond start peta al crear els threads.

   • Utilitza unes llibreries situades a /lib/tls/lib enlloc de les de /lib, un comportament extrany.

   Per veure si era culpa del parche d’openMosix vaig dir que provaria d’instalar un kernel vanilla oficial, i aixi ho he fet. He reinstalat el kernel, i res de res, continua petant igualment.

   Conclusio: Aqui hi ha 2 conclusions xD

La desesperacio m’ha portat a un lloc que creia que mai acabaria anant (molt mal fet per part meva), anar a escriure a la llista de la NPACI Rocks. I nomes ha passat un dia i ja m’han contestat 4 persones. Coses d’aquestes son les que fan creure a la gent amb aixo del soft lliure…
Pos aixo, que m’han contestat, donant-me 2 possibles solucions:

1. Greg Bruno em contesta dient que potser es per culpa de que Ganglia utilitza comunicacio multicast. Aquesta es una de les opcions que ja havia pensat, pero he comprovat el kernel, “Networking Options”, i totes les opcions de TCP/IP multicasting estan marcades. Thanks.

2. Joe Landman, Federico Sacerdoti i David van der Spoel van pel mateix cami, que crec que es l’encertat.
   

   “If I’m not totally wrong, the RHEL kernels are patched for Posix
   threads. This breaks applications which still uses linux threads. In
   your case it could be the other way around. Vanilla kernel with Linux
   threads, application with Posix threads.

   If this is correct it could be resolved by patching your vanilla kernel
   with the posix threads.

   David”

   Doncs, si, els kernels RHEL (RedHat Enterprise Linux) estant parchejats per utilitzar els threads NPTL (Native Posix Threads Library) enlloc dels LinuxThreads, els que van inclosos al nucli per defecte fins a la 2.6. A partir del nucli 2.6 els threads seran d’aquest tipus NPTL, molt mes eficients i lleugers, pro aixo si, tocara migrar les aplicacions per adaptar-les a aquestos nous threads. Per altra banda, a part del kernel els NPTL tambe estan integrats a la libc a partir de la 2.3 em sembla, i es pot descarregar aqui.

   “The problem could be NPTL. RHEL 3 (ROCKS basis) uses it in a back
   ported manner from 2.6 kernels. If you do not use NPTL, some things
   which have been compiled against it will hang, fail, or dump core when
   they try to set up a thread. I saw this a bit with older
   linuxthread-ABI compiled binaries around the RH9 time frame.

   Unfortunately there is no way to make this work short of getting an RH
   kernel compiled and patched the way you need (unless you want to
   integrate their patches into your kernel).

   You might look at starting from
   ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/3WS/en/os/SRPMS/kernel-2.4.21-15.0.3.EL.src.rpm
   and seeing if you can patch from there.

   Joe”

   Aquesta es la resposta mes realista crec. L’unica solucio que tinc es introduir els parches dintre al meu nucli (cosa que aniria malament per a openMosix segurament…). A part, hi ha el problema de trobar els parches que exactament necessito. Pel que fa a investigar aquest kernel he de trobar alguna forma d’”obrir-lo” i veure que te per dins, a part que tb he de buscar els Changelog, ja que alli segur q ho diu.

   “As Joe says, I suspect the problem is in the threading libraries.
   Ganglia is multi-threaded (via pthreads) and we have seen segfaults
   with incompatible kernels. Greceptor uses python threading.

   Do other multi-threaded programs run? (mysql, etc). Also, if you could
   collect a core file from ganglia when it crashes that would be helpful.

   It sounds like you rebuilt and installed your new kernel fine using the
   Rocks infrastructure, which is good news to us

   I am sorry you are having problems with the new beast.

   Federico”

   Haure de parlar amb el David per a que m’ajudi a treure el fitxer core, ja que no en se i crec que es una cosa bastant dificil. Com a minim el Federico es veu afectat xD Pero dona la sensacio com si no haguessin provat mai aquesta funcionalitat, pq el Federico es un dels masters de Rocks.

   Be, amb aixo d’informacio he comencat a indagar… Pro fins i tot amb el google se’m resistia, pro poc a poc he anat trobant coses:

   • El que s’ha encarregat de posar els NPTL al nucli de Linux es diu Ingo Molnar. Dintre de la seva web personal de RedHat he trobat un parche anomenat nptl-2.4.22-ac1-A2, pero no he trobat la versio del kernel correcta per aplicar-lo. Com a curiositat, ja que despres segurament ho haure de mirar, tb te una altra carpeta anomenada tls-patches, que deu estar relacionada amb les llibreries que utilitza el Ganglia. Finalment tambe en te una altra anomenada TUX-patches, que m’acabo de donar compte que surten al menu de Networking del kernel de la Rocks. O sea que tb me l’haure de mirar.

   • Despres he trobat algo que pensava que seria molt sucos, pero al final no ha estat aixi. A aquestaweb he trobat un fitxer anomenat patch-2.4.22-nptl1.patch.bz2, un parche per al kernel 2.4.22, el que necessito.
     

     NPTL1 This is a patchset ripped from RedHat’s 2.4.22-1.2088.nptl kernel. It includes
     2.4.22-ac1 with some fixes as well as the linux-2.4.22-ac1-nptl-A1.patch which enables
     you to compile a NPTL glibc on a 2.4.22
     Linux system.

     L’ultim link no funciona, tota una pena.

     Doncs be, amb aquest parche i el nucli vanilla corresponent he compilat el kernel seguint el procediment establert. La compilacio no m’ha donat cap problema, pero a l’hora de reinstalar ha continuat petant, mira que realment creia que funcionaria…

     Conclusio: A lo millor instalant un altre parche (TUX) funcionara.

   • Un altre filo que he intentat explotar ha estat el de Fedora. Els kernels de Fedora curiosament tenen noms tipo kernel-2.4.22-1.2163.nptl.src.rpm. I si, despres d’estar mirant uns quants Changelogs he vist que els kernels porten el parche per d’NPTL. Intentare instalar un kernel d’aquestos per a la rocks, a veure que me diu. De moment no em deixa, ni per a athlon (que esta mal fet, pq l’hauria de compilar per a Rocks), ni el source, ja que no acabo de dominar el rpm.

     Conclusio: Aquest filo encara es pot investigar.
     Alguns links mes sobre Fedora:

     • Un .spec de la distro.

     • Parche nptl-2.4.22-ac1-A2.
     • Servidor per a la descarga de les actualitzacions de Fedora.
   • Una de les ultimes coses que he trobat ha estat la phil-list — A new thread library for GNU systems, la llista on es discuteixen els canvis dintre el threading de linux.

     Conclusio: He de mirar-la d’aprop, ja que aqui segur que sortiran direccions cap a webs amb els parches.

   • Tambe he buscat informacio sobre que era el TLS. Al final he trobat que son els “Thread Local Storage”, una part q tambe s’ha de modificar per tenir els NPTL. Un document que explica tot sobre el TLS es pot trobar aqui. Suposo que per aixo la rocks te 2 llibreries, les normals de /lib i les TLS a /lib/tls/lib.

     Conclusio: Tambe s’ha d’investigar mes per aqui, pero no se quins fruits donara.

   • Per ultim (que ja es molt tard), fa una estona he trobat que el kernel de la Rocks dintre del menu de Networking Options i dintre de “TCP/IP Networking” te una opcio anomenada “Threaded linUX application protocol accelerator layer (TUX)”, que ve a ser un altre parche que porta incorporat el RHEL. El que no se es que fa aquest parche ni si pot arribar a afectar la fallada del Ganglia. Suposo que no, pero aqui queda.

Bueno, que consti que ho he intentat. Tot un dia intentant instalar Debian pro res, se’m penja tota la estona durant la instalacio. Aixi que ja he tornat a les andades, amb la Gentoo. Tambe he estat configurant tot un dia la Gentoo, pro ha valgut la pena. Fins i tot he instalat el Bootsplash!! (queda xulissim).

Com es pot comprovar encara em falta una cosa per configurar, el teclat castella per poder posar accents xD Pq per defecte m´he posat l’angles (un vici es un vici). Una altra cosa que he d’arreglar es la tarja de so, ja que l’alsa no m’arranca be, pero no es tant important aixo.

Be, un pas mes cap al meu primer (i esperem que no ultim) driver de Linux, gentilesa de Periferics.