# [DISTCC]Dudas con MAKEOPTS (Solucionado)

## Coghan

¿Alguien sabe por algún casual por qué sin usar distcc el handbook http://www.gentoo.org/doc/es/handbook/handbook-amd64.xml?part=1&chap=5#doc_chap4 recomienda usar en el make.conf la variable MAKEOPTS="-jN" poner la como el número de CPU+1 y cuando usas distcc según el manual http://www.gentoo.org/doc/es/distcc.xml#doc_chap2 recomienda poner (CPU*2)+1?

Si esto es correcto ¿puedo redirigir la compilación por distcc a localhost solamente y subir MAKEOPTS como dice el la guía distcc?.

----------

## Inodoro_Pereyra

Redirigir la compilación a localhost y compilar sin distcc sería exactamente lo mismo. Todo dependerá de makeopts justamente...

Si hay otro microprocesador desocupado en tu red, makeopts = ( numero de CPUs implicados * 2 ) + 2 es la mejor combinación aparentemente, al menos en las pruebas que he hecho.

Si no hay ningún otro microprocesador desocupado en tu red, no vas a notar diferencia incrementando el numero de compilaciones en paralelo con makeopts e inclusive si le ponés un numero demasiado alto, por el contrario puede aumentar el tiempo de compilación. 

Aún así, distcc no llega a ser tan eficiente como un buen chroot por red desde la pc "con los recursos" a la carpeta / exportada con NFS de la pc "sin recursos", en caso de que este sea tu problema.

Salud!

----------

## i92guboj

Como ya dicen arriba, ese rodeo no te va a servir para nada.

Aumentando el valor de -j lo único que aumentas es el número de hilos que va a lanzar make a la hora de compilar cosas. Esto tiene básicamente estos efectos:

1.- Lanza más hilos, ocupando más memoria, por supuesto.

2.- Al haber más hilos ejecutándose, hay menos posibilidad de que se pierda tiempo de cpu. Cuando un hilo está haciendo entrada/salida, a veces tiene que esperar y la cpu se queda desaprovechada, pero si hay 100 hilos pues es más difícil que haya cpu desaprovechada en un momento dado.

3.- Como consecuancia de 1, puede que se llene la ram y se comience a hacer swap, por eso no hay que pasarse con el valor de -j. Si llegas a tocar swap entonces el daño será mayor que el beneficio.

Por lo demás, usar distcc para compilar en una sola máquina es superfluo y seguramente hasta ligeramente nocivo, y no tiene mucho sentido. Si lo que quieres es subir el valor de -j, lo puedes hacer tú directamente, no necesitas oscuros trucos, eso si, experimenta y vigila el uso de la ram. Las fórmulas que da el handbook son valores que normalmente son óptimos, pero no es algo que sea matemático.

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> Redirigir la compilación a localhost y compilar sin distcc sería exactamente lo mismo. Todo dependerá de makeopts justamente...
> 
> Si hay otro microprocesador desocupado en tu red, makeopts = ( numero de CPUs implicados * 2 ) + 2 es la mejor combinación aparentemente, al menos en las pruebas que he hecho.
> 
> Si no hay ningún otro microprocesador desocupado en tu red, no vas a notar diferencia incrementando el numero de compilaciones en paralelo con makeopts e inclusive si le ponés un numero demasiado alto, por el contrario puede aumentar el tiempo de compilación. 
> ...

 

En mis prueba estoy usando un PC con un amd64 de doble núcleo haciendo de servidor distcc pero compilando para si mismo sin este, el cliente distcc es un portátil con un Amd Turion64 mono-núcleo  con buenos recursos y uso distcc para distribuir la carga entre los dos ordenadores al compilar para el portátil. No quiero usar el portátil para ayudar al sobremesa, el solito ya se basta, sino al revés.

Si en el sobremesa tengo el MAKEOPTS="-j3" según recomienda el handbook (número de CPU+1 sin distcc), tres hilos simultáneos en mi caso, y en el portátil sin distcc "-j2", ¿porqué al usar distcc en el portátil he de poner "-j7" como dice la guía distcc o "-j8" como dices tú?, esto supondría 7 u 8 hilos paralelos entre los dos ordenadores, sin embargo sin distcc lo recomendado si los sumamos independiente no se recomienda más de "-j3" para uno y "-j2" para el otro, 5 hilos.

 *i92guboj wrote:*   

> 1.- Lanza más hilos, ocupando más memoria, por supuesto.
> 
> 2.- Al haber más hilos ejecutándose, hay menos posibilidad de que se pierda tiempo de cpu. Cuando un hilo está haciendo entrada/salida, a veces tiene que esperar y la cpu se queda desaprovechada, pero si hay 100 hilos pues es más difícil que haya cpu desaprovechada en un momento dado.
> 
> 3.- Como consecuancia de 1, puede que se llene la ram y se comience a hacer swap, por eso no hay que pasarse con el valor de -j. Si llegas a tocar swap entonces el daño será mayor que el beneficio. 

 

Entonces, siguiendo tus consejos, aun usando distcc, para no cargar la CPU de ambos equipos entiendo que usar en el portátil MAKEOPTS="-j5" sería lo óptimo.

Por otro lado usando:

```
DISTCC_DIR="/var/tmp/.distcc/" distccmon-gui
```

 en la máquina cliente obtengo el estado de compilación de todos los hilos actuales de la compilación, sin embargo me interesa saber como controlar el uso que se está haciendo en el servidor desde él mismo. ¿Como podría hacerlo?.

En caso de que necesite compilar en ambas máquinas simultáneamente, ¿distcc es inteligente a la hora de no sobrecargar el servidor o por el contrario he de parar distcc?.

En caso de que necesite compilar con el portátil fuera de la red del servidor distcc, existe alguna manera de poner un MAKEOPTS dinámico para que se adapte a no tener distcc?.

----------

## Inodoro_Pereyra

El valor que te sugiero para makeopts es resultado de mi experimentación simplemente donde armé una granja distcc de 5 pc todas diferentes en capacidad, midiendo tiempos de compilación con time.

Un valor mayor me incrementaba los tiempos de compilación pero las pc iban desde un athlon (k7) de 1200 hasta un athlon64 3500+ en su momento... Probablemente alguna de las pc me ralentizaba a las demás al incrementar el valor...

Vas a tener que jugar con este valor e ir probando que resultados obtenés... Hoy en día no lo uso mas, chroot me da mejores resultados.

Sobre tu otra pregunta, no la termino de entender, si ves todos los procesos de compilación desde el cliente y lo que necesitas ver es el estado en el server, un buen top o htop es lo que usaría yo.

No sé que tan inteligente es distcc cuando además se compile en local pero muy probablemente toda la carga la distribuyan el gcc y el kernel y a menos que hayas cambiado el niceness será lo mas parejo posible.

En el caso de que distcc no se pueda conectar con el server siempre compilará en local, un makeopts dinámico no se me ocurre como implementarlo... A ver que dice i92 que seguramente tiene la respuesta.

Salud!

----------

## Coghan

 *Inodoro_Pereyra wrote:*   

> Vas a tener que jugar con este valor e ir probando que resultados obtenés... Hoy en día no lo uso mas, chroot me da mejores resultados.

 

Usar chroot vale si la maquina para la que compilas es lenta, pero en mi caso quiero usar las dos máquina rápidas para mejorar el tiempo de instalación.

 *Quote:*   

> Sobre tu otra pregunta, no la termino de entender, si ves todos los procesos de compilación desde el cliente y lo que necesitas ver es el estado en el server, un buen top o htop es lo que usaría yo.

 

Aquí lo que necesito es saber para que equipos/hilos está trabajando el servidor disctcc desde el mismo servidor, un top no me dirá quien manda el proceso.

 *Quote:*   

> No sé que tan inteligente es distcc cuando además se compile en local pero muy probablemente toda la carga la distribuyan el gcc y el kernel y a menos que hayas cambiado el niceness será lo mas parejo posible.

 

Siempre he entendido que hacer varios emerge en paralelo no es nada bueno, por eso me planteo que si distcc está trabando y quiero compilar en local sin distcc si no tendré resultados incorrectos o desmejora del rendimiento. Por eso quiero también saber como controlar lo de la pregunta de arriba.

 *Quote:*   

> En el caso de que distcc no se pueda conectar con el server siempre compilará en local, un makeopts dinámico no se me ocurre como implementarlo... A ver que dice i92 que seguramente tiene la respuesta.

 

Que compilará en local lo tengo claro, pero lo hará con el número de hilos que se configuró para distcc. Veamos que dice el maestro.  :Cool: 

----------

## ColdWind

Un MAKEOPTS "dinámico" se puede implementar en /etc/portage/bashrc.

AVISO: NADA que hagas en ese fichero está soportado oficialmente, y si rompes algo por esa via es probable que te digan que te vayas a llorar a otra parte.

La forma de implementarlo que me ocurre es bastante guarra y seria pillar la lista de hosts con distcc-config --get-hosts, hacer un ping a cada uno de ellos para obtener el número de hosts operativos y en función de eso exportar MAKEOPTS con el valor adecuado. El problema es que eso no tendría en cuenta el caso de que tu servidor esté online pero no esté corriendo distccd.

Conclusión, en lugar de un MAKEOPTS "dinámico" será mejor que uses MAKEOPTS="-j2" emerge blah cuando estés compilando únicamente en local.

----------

## gringo

Las versiones de distcc que están en ~arch tienen un nuevo USE avahi, con lo que se consigue una detección automática de las máquinas implicadas y las compilaciones a distribuir se configuran automáticamente.

https://bugs.gentoo.org/show_bug.cgi?id=203874

Los chavales de bashrc-ng tb. tienen un módulo que hace mas o menos lo que dice ColdWind.

por si a alguien le resulta de utilidad ...

saluetes

----------

## Coghan

 *gringo wrote:*   

> Las versiones de distcc que están en ~arch tienen un nuevo USE avahi, con lo que se consigue una detección automática de las máquinas implicadas y las compilaciones a distribuir se configuran automáticamente.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=203874

 

¡Perfecto!, Muchas gracias @gringo.

Justamente eso es lo que estaba buscando, funciona genial, el solito detecta las máquinas de la red que tienen el demonio distccd trabajando y autodetecta el número de CPUs. La forma de hacerlo es la siguiente:

Actualizar sys-devel/distcc desde ~amd64 o ~x86 con el USE avahi activado en todas las máquinas de la red.

No olvidarse de etc-update, y revisar los cambios de /etc/conf.d/distccd y reiniciar el demonio distccd en todas las máquinas.

Configurar los hosts de distcc de la siguiente manera en todos los clientes distcc:

```
sudo distcc-config --set-hosts +zeroconf
```

Cambiar en /etc/make.conf la variable MAKEOPTS de todos los clientes distcc como sigue:

```
MAKEOPTS="-j 'distcc -j'"
```

Para comprobar que funciona ejecuta:

```
distcc -j
```

 y te devolverá un número, este es el valor que asigna a MAKEOPTS.

Si quieres ver que servidores distcc están activos en tu red ejecuta 

```
distcc --show-hosts
```

 y te devolverá la IP del servidor:puerto/hilos

En mi caso me pilla el valor 8 para un AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ de doble núcleo. Desconozco en base a que criterio calcula el número de hilos, pero no tiene nada que ver con lo que recomienda los manuales que comentamos arriba.

EDITO: Había un error en make.conf debe ser como está ahora.

----------

## Stolz

 *Coghan wrote:*   

> Cambiar en /etc/make.conf la variable MAKEOPTS de todos los clientes distcc como sigue:
> 
> ```
> MAKEOPTS="-j 'distcc -j'"
> ```
> ...

 

Coghan, ¿te funciona así?

Al ver que los nuevos ebuilds de distcc soportan avahi me he puesto a buscar información como loco y he llegado a este hilo. Al ver la solución que propones se me han iluminado los ojos pero al probarla no me funciona. He probado con 

```
MAKEOPTS="-j 'distcc -j'"
```

 y con 

```
MAKEOPTS="-j `distcc -j`"
```

 pero en ambos casos no se evalua MAKEOPTS sino que se pasa al make el valor literal que he puesto en make.conf y claro, protesta.

En el trabajo tengo bastantes ordenadores y en casa solo 2. Había pensado en poner en MAKEOPTS un valor alto para contemplar ambos casos pero así el consumo de ram cuando estoy en casa se dispara por lanzar tantos hilos en el mismo ordenador y no compensa usar distcc. Lo ideal y lo que me gustaría es que el valor de MAKEOPTS se calcule de forma dinámica y que siempre valga lo mismo que el comando 'distcc -j' para así detectar los cambios en los ordenadores disponibles en la red.

¿hay alguna forma de hacer que se evalue de forma integrada con emerge? 

Saludozzzzzzz

----------

## gringo

con avahi no te puedo ayudar, no lo uso. Lo probé y no distribuía tan agresivamente como a mi me gustaba asi que no me paré mucho en ver como funcionaba. 

Como comenté arriba, los de bashrc-ng tienen un módulo que mas o menos hace lo que comentaba Coldwind, detecta a base a pings los hosts disponibles, no es un método que me guste y no tengo ni idea de si funciona con versiones recientes de portage. Prueba a ver ...

que por cierto, ya que se habla de este tema-> http://planet.gentoo.org/developers/zmedico/2008/07/23/portage_parallel_builds

saluetes

----------

## Inodoro_Pereyra

 *http://planet.gentoo.org/developers/zmedico/2008/07/23/portage_parallel_builds wrote:*   

> -keep-going
> 
> 	Continue as much as possible after an error. When an error
> 
> 	occurs, dependencies are recalculated for remaining packages
> ...

 

Siempre me pregunté que tan dificil sería implementar algo semejante... Si les ha tomado tanto tiempo se ve que no era nada facil la cosa. Ya me puedo desprender de esos scripts que usaba para dejar compilando de noche  :Very Happy: 

Gracias gringo!

----------

## Coghan

 *Stolz wrote:*   

>  *Coghan wrote:*   Cambiar en /etc/make.conf la variable MAKEOPTS de todos los clientes distcc como sigue:
> 
> ```
> MAKEOPTS="-j 'distcc -j'"
> ```
> ...

 

¡Vaya, que despiste!, no había corregido esto. Cuando hice las pruebas me dio mucho la lata el asunto, al final la línea la tengo de la siguiente manera:

```
MAKEOPTS=" -j $(distcc -j)"
```

Pero si no tengo la variable DISTCC_HOSTS exportada no funciona el invento y distcc se queja, lo solucioné añadiendo esta al make.conf antes de MAKEOPTS

```
export DISTCC_HOSTS="host1 host2 host3"
```

Si un host esta fuera de línea no devolverá resultado y no sumará hilos al resultado final.

----------

## Coghan

Esto me ha obligado buscar más información porque este tema va cambiado de revisión en revisión, así que toca la lectura profunda de la última página man disponible:

http://distcc.googlecode.com/svn/trunk/doc/web/man/distcc_1.html

Esta habla sobre cargar la variable DISTCC_HOSTS, también comenta algo sobre poder asignar hilos a mano por host. aún no la he leído completa.

----------

## Stolz

Gracias por las respuestas y por los enlaces. Las nuevas features de Portage 'se salen'  :Smile: 

No se por qué pero no me ha funcionado modificando make.conf con

```
MAKEOPTS=" -j $(distcc -j)"
```

incluso poniendo DISTCC_HOSTS (con y sin export).

Al final lo he conseguido con un alias. Tal vez no sea lo más elegante pero hace justo lo que quiero, usar un valor de MAKEOPTS dinámico en función de los ordenadores de la red que estén disponibles para compilar en ese instante:

```
alias emerge="sed -i s/^MAKEOPTS.*/MAKEOPTS=\"-j`distcc -j`\"/ /etc/make.conf;emerge"
```

Saludozzzzzzz

----------

## gringo

 *Quote:*   

> Gracias por las respuestas y por los enlaces. Las nuevas features de Portage 'se salen' 

 

pues hay mas -> http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set  :Wink: 

 *Quote:*   

> No se por qué pero no me ha funcionado modificando make.conf

 

estoy hablando de memoria, pero si mal no recuerdo no cambié para nada el MAKE_OPTS cuando jugueteé con avahi/ distcc, tan sólo añadí +zeroconf a mi /etc/distcc/hosts, configuré distcc para que usara avahi y reinicié distcc en las máquinas implicadas.

Normalmente sé las máquinas a las que puedo distribuir, así que simplemente tengo un valor -j alto en mi make.conf y para paquetes que sé que no compilan con distcc ( o si sé que no tengo mas máquinas disponibles), simplemente tengo un alias en mi bashrc :

```
alias ncemerge="FEATURES="-distcc" MAKE_OPTS="-j2" emerge -av"
```

y con eso me apaño.

saluetes

----------

## Inodoro_Pereyra

 *Zack Medico wrote:*   

> I've implemented new @live-rebuild and @module-rebuild package sets, and added them to the default sets.conf file for the next sys-apps/portage release

 

Este Zack me lee el pensamiento!  :Very Happy: 

Gracias gringo. (una vez mas)

Salud!

----------

## gringo

um, el caso es que a través del planet de gentoo ( concretamente este artículo ) me entero de que existe una nueva versión en desarollo de distcc. Acudo a su web, entro en su man y (entre otras cosas) leo un par de cosas interesantes :

 *Quote:*   

> [...]The major improvement in distcc 3.0 is the inclusion of "pump" mode. In "pump" mode, distcc sends source file with their included header files to the compilation servers, which now carry out both preprocessing and compilation. As a result, distcc-pump can distribute files up to 10 times faster to compilation servers than distcc.
> 
> distcc-pump is easily deployed through a wrapper script around an existing build command, such as 'make'. It is currently best suited for cross compilation, which is less demanding of include directory configurations[...]
> 
> [...]Another alternative if you're using pump mode is to set the DISTCC_POTENTIAL_HOSTS environment variable; in that case, the pump script will use "lsdistcc" to set DISTCC_HOSTS, automatically eliminating hosts that are down or inaccessible or that don't have distccd running.[...]

 

como mola !  :Smile: 

http://code.google.com/p/distcc/

saluetes

----------

## Inodoro_Pereyra

Que hacés cuando no vas por la red leyendo manuales y changelogs gringo?  :Very Happy: 

Me pregunto como irá sobre internet... Uso distcc sobre una conexión con 64KB de upstream y me va bastante bien, me imagino que en modo pump debe consumir mas ancho de banda... Habrá que probar, gracias!

Salud!

----------

## Coghan

La idea es conseguir un MAKEOPTS dinámico según los servidores distcc activos en la red local.

Hasta que la versión 3 de distcc esté disponible (gracias gringo por la info), esto es lo que he ido descubriendo hasta ahora con las versiones actuales de portage:

+zeroconf Solo consigo que autodetecte el servicio distccd en la máquina local, no he conseguido que detecte el servicio ejecutado en otra PC de la red local, he revisado tanto puertos TCP/3632 (distccd) como UDP/5353 (zeroconf), como resolución dns inversa, pero sin conseguir resultados. Por lo tanto decidí no usar esta opción en el DISTCC_HOSTS, pero como USE de sys-devel/distcc debe estar activa para tener la opción 'distcc -j'

DISTCC_HOSTS Debe estar definida como variable de entorno global, no funciona si la ponemos en /etc/make.conf, la podéis poner en vuestro .bashrc como en el de root, yo lo he puesto en /etc/env.d/02distcc. Colocar aquí la lista de todos los hosts que tenéis ejecutando el demonio distccd, recomiendo ponerlo del modo hosts:3632/4 (equipo:puerto/hilos), si no especificáis los hilos al realizar un distcc -j este asignará unos valores que desde mi punto de vista no son reales, como esto es muy subjetivo depende de cada uno como quiera configurarlo. Yo estoy usando 2 hilos por procesador bajo distcc y el recomendado por el manual distcc de Gentoo, procesadores+1.

SCRIPT: He puesto el siguiente script makeopts.sh bajo /usr/local/bin, este directorio también está bajo mi PATH. Primero detecta si tienes distcc habilitado en tu make.conf, si no es así omite la búsqueda de servidores distcc y ejecuta emerge de la manera tradicional, para esto es importante tener en nuestro make.conf la variable MAKEOPTS="-jN" normal cuando no usamos distcc.

El siguiente paso es detectar los hosts que hemos configurado antes en nuestra variable DISCTCC_HOSTS, incluso tiene en cuenta  si aquí hemos puesto además del hosts el puerto y los hilos y el resto de opciones que puedes configurar en esta variable, luego comprueba uno a uno si el servicio está levantado mediante nmap al puerto 3632, si alguno no está activo no lo tiene en cuenta en la configuración final. 

finalmente pasa la variable DISTCC_HOST final para lanzar emerge con el MAKEOPTS adecuado. Estás variables no se mantienen de forma global por lo tanto se calcularán en cada emerge que se realice.

```
#!/bin/bash

# Llocaliza servidores distcc activos en la red local para

# poder asignar a nuestra variable MAKEOPTS en

# /etc/make.conf un valor dinámico.

TEMPHOSTS=""

. /etc/make.conf

if [ `echo ${FEATURES} | grep -q -e distcc ; echo $?` == 0 ] && [ `echo ${FEATURES} | grep -q -e -distcc ; echo $?` != 0 ]; then

   for DHOSTS in ${DISTCC_HOSTS}; do

             HOST=${DHOSTS#*@}

             HOST=${HOST%:*}

             HOST=${HOST%/*}

             NMAP=$(nmap -p3632 -PN -n ${HOST} | grep open)

             if [ -n "$NMAP" ];then

         TEMPHOSTS="${TEMPHOSTS} ${DHOSTS}"

             fi

   done

   DISTCC_HOSTS="${TEMPHOSTS}"

   MAKEOPTS="-j$(distcc -j)" emerge $@

else

   emerge $@

fi

```

ALIAS Finalmente he creado el siguiente alias en mi $HOME/.bashrc

```
alias emerge='makeopts.sh $@'
```

Ahora al hacer un emerge --info |grep MAKEOPTS obtendréis resultados diferentes en función de si tenéis distcc activado y/o los demonios distccd activos en todas las máquinas de la red local. 

Creo que no se me queda nada atrás, si encontráis una manera mejor de hacerlo os agradecería que lo comentarais.

----------

## gringo

se me olvidó decir ayer que en el paquete del nuevo distcc, en la carpeta contrib, está el siguiente script ( entre otros) :

```
#! /bin/sh

# make-j script from Alexandre Oliva <aoliva@redhat.com> for use with distcc

# Tests which machines are up, and runs Make with concurrency set

# appropriately.

hostlist=$DISTCC_HOSTS

distcc_port=4200

DISTCC_HOSTS=

count=0

for h in $hostlist; do

  echo trying $h... >&2

  if test "x$h" = xlocalhost || nc -z $h $distcc_port; then

    echo added $h... >&2

    DISTCC_HOSTS=`echo $DISTCC_HOSTS $h` # remove leading blank

    count=`expr $count + 1`

  fi

done

export DISTCC_HOSTS

exec make -j $count ${1+"$@"}
```

requiere netcat como se puede ver y sería bastante fácil incluir / combinar esto en el script de Coghan si a alguien le interesa.

cuando tenga un segundo escribiré un ebuild para la nueva versión, no lo he mirado mucho, pero parece que simplemente con renombrar el ebuild y retocar/añadir dos cosillas debería estar.

saluetes

----------

## Coghan

 *gringo wrote:*   

> requiere netcat como se puede ver y sería bastante fácil incluir / combinar esto en el script de Coghan si a alguien le interesa.

 

Te he tomado la palabra y he combinado la parte de netcat y añadidos algunos cambios más. No me gusta como este script calcula el número de hilos, solo suma un hilo por cada servicio activo, no tiene en cuenta que pueden haber varios procesadores, por lo que sigo con la idea de configurar el número de hilos a mano a la hora de definir cada hosts con máquina:puerto/Nhilos.

Ya no es necesario tener la variable DISTCC_HOSTS cargada en el entorno, ahora lee la lista con el comando distcc-config --get-hosts que previamente habremos configurado con distcc-config --set-hosts "hosts1 hosts2", según reza el manual de la documentación de Gentoo (para seguir con la norma). Aquí hay que tener en cuenta al cambiar los hosts, reiniciar el demonio distccd y volver a reiniciar la consola de lo contrario no se harán patentes los cambios.

Ahora el script detecta el puerto, si lo hemos definido con 'distcc-config' o usa el puerto por defecto si no, para comprobar si el servicio está activo.

También detecta si no existe ningún servidor distccd activo en la lista de hosts y en este caso usa el MAKEOPTS por defecto para el PC local que hemos definido en nuestro make.conf.

He añadido dos formas de detectar si el puerto que usa distccd está abierto con nmap y con netcat. He visto que si ningún hosts está caído, netcat es más rápido en responder, pero en caso contrario nmap gana. Cuando son pocos servidores este tiempo es insignificante, pero si tienes una buena batería de estos puede demorar considerablemente. Dejo a la elección de cada uno cual prefiere, solo hay que descomentar la línea adecuada.

Además detecta si algunos de los servidores utiliza distcc a través de ssh, se conecta a este servidor y comprueba si el servicio se está ejecutando. Para que no os pida la contraseña el servidor ssh cada vez, así como los parámetros de la conexión, hay que configurar las opciones en ~/.ssh/

Podéis utilizar para ello este manual

Como nota final no olvidar poner el alias emerge='makeopts.sh $@' en el .bashrc del root también, si no al lanzar emerge con sudo el invento no funcionará.

```
#!/bin/bash

# Localiza servidores distcc activos en la red local para

# poder asignar a nuestra variable MAKEOPTS en

# /etc/make.conf un valor dinámico.

TEMPHOSTS=""

#HOSTSLIST=$(distcc-config --get-hosts)

HOSTSLIST=$(distcc --show-hosts | xargs)

. /etc/make.conf

if [ `echo ${FEATURES} | grep -q -e distcc ; echo $?` == 0 ] && [ `echo ${FEATURES} | grep -q -e -distcc ; echo $?` != 0 ]; then

   for DHOSTS in ${HOSTSLIST}; do

        HOST=${DHOSTS#*@}; HOST=${HOST%:*}; HOST=${HOST%/*}

        DPORT=${DHOSTS#*:}; DPORT=${DPORT%/*}

        if [ `echo ${DHOSTS} |grep -q -e @ ; echo $?` == 0 ]; then

            SHOST=${DHOSTS%:*}; SHOST=${SHOST%/*}

            SSH=$(ssh ${SHOST} ps -A |grep distccd)

            if [ -n "${SSH}" ]; then

                TEMPHOSTS="${TEMPHOSTS} ${DHOSTS}"

            fi

        else

            calc=("$DPORT"/"$DPORT")

            if  [ $calc != 1 ]; then DPORT=3632; fi

            if nc -z $HOST $DPORT ;then

                TEMPHOSTS="${TEMPHOSTS} ${DHOSTS}"

            fi

        fi

   done

   if [ -n "${TEMPHOSTS}" ]; then

        DISTCC_HOSTS="${TEMPHOSTS}" MAKEOPTS="-j$(distcc -j)" emerge $@

   else

        DISTCC_HOSTS="" emerge $@

   fi

else

   emerge $@

fi 

```

Si detectáis algún error en alguna de las combinaciones agradezco que lo comentéis.

EDITO:He modificado el script para descartar definitivamente nmap, cuando la máquina está apagada o tiene habilitado el rechazo de paquetes ICMP, nmap se queda a la espera con la opción -PN y sin la opción el resultado puede ser falso. También he cambiado la forma final de lanzar emerge debido a que si la variable DISTCC_HOSTS está cargada en el entorno esta tiene preferencia.

EDITO:Modificada la variable HOSTSLIST para que funcione con avahi. Aporte de Stolz

----------

## Stolz

A mi la opción zeroconf sí me funciona y me puedo olvidar DISTCC_HOSTS. Me dio problemas porque no había compilado avahi con USE="dbus". Por si es un problema de red, si usas IPtables puedes configurarlo para que guarde en el log del sistema los paquetes que está rechazando para ver si detectas el problema:

iptables -N LOGDROP

iptables -A LOGDROP -j LOG

iptables -A LOGDROP -j DROP

Espero que sirva de algo

----------

## gringo

 *Quote:*   

> Me pregunto como irá sobre internet... Uso distcc sobre una conexión con 64KB de upstream y me va bastante bien, me imagino que en modo pump debe consumir mas ancho de banda... Habrá que probar, gracias! 

 

si, es de esperar que en modo pump consuma algo mas, igual habilitando la compresión se reduce algo pero no creo que sea gran cosa.

Una idea interesante sería crear una especie "red de compilación distribuida para usuarios gentoo", una idea que ya surgió hace bastante tiempo pero que nunca llegó a ver la luz. 

En principio haciéndolo sobre ssh, capando y tuneando distcc un poco y creando un listado actualizado de máquinas implicadas debería estar. Alguien se anima ?

@Coghan - buen trabajo  :Smile: 

el ebuild va a tener que hacerlo alguien que controle del tema, no me di cuenta en su momento que gentoo parchea distcc con bastantes cosillas y portar alguno de ellos no es moco de pavo. No lo he mirao mucho tampoco, este fin de semana quiero mirarlo con un poco mas de calma, pero toca esperar me temo.

saluetes

----------

## Coghan

 *Stolz wrote:*   

> A mi la opción zeroconf sí me funciona y me puedo olvidar DISTCC_HOSTS. Me dio problemas porque no había compilado avahi con USE="dbus". Por si es un problema de red, si usas IPtables puedes configurarlo para que guarde en el log del sistema los paquetes que está rechazando para ver si detectas el problema:
> 
> iptables -N LOGDROP
> 
> iptables -A LOGDROP -j LOG
> ...

 

Sigue igual, ya tenía dbus en la USE de avahi en las dos máquinas con las que estoy probando, también había desactivado las iptables para hacer las pruebas y solo me detecta la ip de la interface local, además me sigue sin gustar como asigna los hilos pues me lanza 4 hilos para un procesador mononúcleo.

Otro falta que le veo a +zeroconf en que no tendrá en cuenta los equipos fuera de la red local y los que funcionen distccd bajo ssh.

Por otro lado tengo estos permisos en el directorio /etc/distcc d-wxrwS--t, ¿son correctos?.

 *gringo wrote:*   

> Una idea interesante sería crear una especie "red de compilación distribuida para usuarios gentoo", una idea que ya surgió hace bastante tiempo pero que nunca llegó a ver la luz.
> 
> En principio haciéndolo sobre ssh, capando y tuneando distcc un poco y creando un listado actualizado de máquinas implicadas debería estar. Alguien se anima ? 

 

Parece algo utópico y muy complejo de mantener, habría que crear diferentes ramas de compilación para cada arquitectura y cada versión de gcc, aparte de implementar algún control de límites de uso por temas de seguridad, con lo que consume recursos la compilación no creo a nadie le guste la merma en su equipo.

 *Quote:*   

> @Coghan - buen trabajo 

 

Gracias, jeje. No soy programador, es mi "ToDo" personal, pero esto me vale para hacer mis prácticas en bash.

----------

## gringo

 *Quote:*   

> Parece algo utópico y muy complejo de mantener, habría que crear diferentes ramas de compilación para cada arquitectura y cada versión de gcc, aparte de implementar algún control de límites de uso por temas de seguridad, con lo que consume recursos la compilación no creo a nadie le guste la merma en su equipo.

 

se hace un filtrado previo de versiones de gcc y arquitecturas disponibles : si no hay ningún nodo compatible con tu sistema no podrás usar la red, así de simple. No se trata de tener un toolchain para cada arquitectura disponible. Por lo del control de recursos, esto sería (mas o menos) como un seti@home, supongo que los que lo usen sabrán de que va y como configurar distcc.

sólo es una idea, sé de unos holandeses que lo tienen funcionando para bsd ( sólo para sparc y x86).

saluetes

----------

## Coghan

@gringo, la idea me parece buena, estaría dispuesto a testear si hubiese un proyecto iniciado, solo por el placer de saber como funciona.

Se me ocurre que la caché para este servicio deberá ser muy elevada para ahorrar tiempo de procesador, en los casos de peticiones muy repetidas.

Conocí seti@home hace años, jeje, parece que no fuí el único raro que lo probó.

----------

## Stolz

Pongo esto aquí porque este hilo se ha convertido en el sitio con más información útil sobre distcc (es más, yo diría que es el único post del foro, incluyendo los demás idiomas, donde se trate el tema de distcc+zeroconf). 

Hace un par de días que tenemos versión nueva de Distcc con novedades interesantes *distcc 3.0 wrote:*   

> 
> 
> The major improvement in distcc 3.0 is the inclusion of "pump" mode. In "pump" mode, distcc sends source file with their included header files to the compilation servers, which now carry out both preprocessing and compilation. As a result, distcc-pump can distribute files up to 10 times faster to compilation servers than distcc.
> 
> distcc-pump is easily deployed through a wrapper script around an existing build command, such as 'make'. Pump mode uses the system header files from the compilation servers, so it works best if all of your compilation servers are configured identically, or if you use cross-compilers that come with their own system header files. 

 

Coghan, he estado usando distcc con avahi y para pocas máquinas (5 o 6) me ha venido de perlas pero ahora que tengo unas cuantas más, hay veces que no se por qué no detecta algunas máquinas. Parece ser totalmente aleatorio porque ejecutando tres veces seguidas "distcc --show-hosts" obtengo resultados totalmente distintos. Ahora estoy usando tu script y funciona muy bien. La única modificación que he hecho es reemplazar

```
HOSTSLIST=$(distcc-config --get-hosts) 
```

por

```
HOSTSLIST=$(distcc --show-hosts | xargs)
```

y así funciona tanto si tienes Avahi como si configuras los hosts de forma manual.

Por cierto, la última vez se me olvidó incluir la regla de firewall para que funcione avahi

```
iptables -A INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
```

Saludozzzzzzzzzzzz

----------

## gringo

alguien ha estado probando esto del pump mode ? Si es asi, es cosa mía o esto no se puede usar conjuntamente con ccache ?

No tengo acceso a ningún gentoo ahora mismo, pero cuando probé este fin de semana obtenía toneladas de mensajes en plan "distcc error : pump mode no puede distribuir cabeceras preprocesadas (o algo así), lo que me hace pensar que o bien es ccache, o alguna opción que le paso al compilador y que se ahostia con distcc o simplemente algo que hago mal.

DISTCC_POTENTIAL_HOSTS no he podido probarlo tampoco.

saluetes

----------

## Coghan

 *gringo wrote:*   

> alguien ha estado probando esto del pump mode ? Si es asi, es cosa mía o esto no se puede usar conjuntamente con ccache ?
> 
> No tengo acceso a ningún gentoo ahora mismo, pero cuando probé este fin de semana obtenía toneladas de mensajes en plan "distcc error : pump mode no puede distribuir cabeceras preprocesadas (o algo así), lo que me hace pensar que o bien es ccache, o alguna opción que le paso al compilador y que se ahostia con distcc o simplemente algo que hago mal.

 

He visto en el manual que para usar conjuntamente con ccache hay que decírselo explícitamente, doy por entendido que emerge ya lo hace, dudo mucho que haya que agregar esta variable al make.conf, ¿Alguien puede confirmarlo?:

 *man distcc wrote:*   

> ccache is a program that speeds software builds by caching the results of compilations. ccache is normally called before distcc, so that results are retrieved from a normal cache. Some experimentation may be required for idiosyncratic makefiles to make everything work together. 
> 
>  The most reliable method is to set 
> 
> CCACHE_PREFIX=distcc

 

Pero también dice que esto no vale con pump, aunque no dicen porqué, lo siento gringo   :Sad:  :

 *man distcc wrote:*   

> distcc's pump mode is not compatible with ccache.

 

 *Stolz wrote:*   

> Coghan, he estado usando distcc con avahi y para pocas máquinas (5 o 6) me ha venido de perlas pero ahora que tengo unas cuantas más, hay veces que no se por qué no detecta algunas máquinas. Parece ser totalmente aleatorio porque ejecutando tres veces seguidas "distcc --show-hosts" obtengo resultados totalmente distintos. Ahora estoy usando tu script y funciona muy bien. La única modificación que he hecho es reemplazar
> 
> ```
> HOSTSLIST=$(distcc-config --get-hosts)
> ```
> ...

 

Yo no tengo tantas máquinas en paralelo pero parece el mismo problema que me surgió con las pruebas y que me hizo liarme pensando al principio que sí funcionaba bien. De todas formas me sigo quedando con el script incluso usándolo con distcc3, obtengo un mejor control sobre a que máquinas distribuir la compilación y el número de hilos de cada una. Muchas gracias por la línea que apuntas, la anoto, y me alegra que te haya gustado el script, supongo que se podrá mejorar. Demos tiempo para ver que partido se le puede sacar a esa versión de distcc.

----------

## gringo

 *Quote:*   

> He visto en el manual que para usar conjuntamente con ccache hay que decírselo explícitamente, doy por entendido que emerge ya lo hace, dudo mucho que haya que agregar esta variable al make.conf, ¿Alguien puede confirmarlo?: 

 

ccache lo tengo activado desde que instalé el sistema, simplemente emerge -av ccache, añadir ccache a las FEATURES del make.conf y un par de variables de entorno pal bashrc ( o lo que uses). Luego vete controlando que realmente lo estás usando.

El mío ahora dice esto:

```

ccache -s 

cache directory                     /var/tmp/ccache

cache hit                          34656

cache miss                         75304

called for link                     9620

multiple source files                  2

compile failed                      2317

preprocessor error                   971

not a C/C++ file                    3981

autoconf compile/link              20563

unsupported compiler option         7346

no input file                      14583

files in cache                    150608

cache size                           1.4 Gbytes

max cache size                       4.0 Gbytes

```

es una instalación reciente pero tiene un hit bastante decente ya  :Smile: 

 *Quote:*   

> distcc's pump mode is not compatible with ccache.

 

je, cierto, se me habia olvidao RTFM  :Razz: 

No había entendido muy bien esto del pump mode pero parece normal que no se pueda usar ccache con pump, porque simplemente no la vas a usar. 

Tb se necesita habilitar la compresión si se usa pump mode.

saluetes

----------

## Coghan

jeje, ya se como se usa ccache en portage, me refería a la nueva versión de distcc y la variable CCACHE_PREFIX=distcc y el uso conjunto de ccache con distcc.

----------

## gringo

 *Coghan wrote:*   

> jeje, ya se como se usa ccache en portage, me refería a la nueva versión de distcc y la variable CCACHE_PREFIX=distcc y el uso conjunto de ccache con distcc.

 

ah, ok.

Yo no hice ninguna configuración a mayores de la se siempre y distcc/ccache me funcionan igual de bien hasta donde yo sé ( obviamente sin modo pump).

saluetes

----------

## Txema

 *Quote:*   

> y un par de variables de entorno pal bashrc ( o lo que uses)

 

¿hmm? ¿exactamente de qué variables hablas?

 *Quote:*   

> ccache -s
> 
> cache directory                     /home/chema/.ccache
> 
> cache hit                           1601
> ...

 

Mi cache hit es patético, y eso que hace ya unos meses que lo instalé ^^"

----------

## ekz

 *Txema wrote:*   

> 
> 
> Mi cache hit es patético, y eso que hace ya unos meses que lo instalé ^^"

 

Prueba ejecutarlo con el usuario root, yo me asusté al ver que el mío indicaba

```
ekz@localhost ~ $ ccache -s 

cache directory                     /home/ekz/.ccache

cache hit                              0
```

Pero luego desde root

```
localhost ~ # ccache -s

cache directory                     /root/.ccache

cache hit                          11220
```

Tendré más cuidado al usar sudo+emerge  :Razz:   :Laughing: 

Saludos!

*EDIT:  *man ccache wrote:*   

>        CCACHE_DIR
> 
>               the  CCACHE_DIR environment variable specifies where ccache will
> 
>               keep its cached compiler output. The default is "$HOME/.ccache".
> ...

 

**EDIT 2: Le configuré la ruta correctamente, y ahora   :Smile:  :

```
localhost ~ # ccache -s

cache directory                     /var/tmp/ccache

cache hit                         166286
```

----------

## gringo

 *Quote:*   

> ¿hmm? ¿exactamente de qué variables hablas? 

 

el que te comenta ekz y CCACHE_SIZE, algo trivial vamos, ambos los pego en el bashrc de mis usuarios, indicando en todos el mismo directorio ( /var/tmp/ccache en mi caso) para la caché. Si no creo que se define automáticamente en un archivo en /etc/env.d/ por defecto.

En mi opinión no tiene sentido que cada usuario tenga su propio caché ( en una instalación gentoo por defecto vaya ) y va en contra de lo que se supone que ccache tiene que hacer.

saluetes

----------

