Aug 11

Problema.

Condor inicia de manera exitosa manualmente, sin embargo no se inicia automáticamente durante el inicio del sistema operativo.

Los logs del nodo, tanto de Condor como del sistema operativo, no muestran ningún mensaje de error, sin embargo se muestra el siguiente mensaje durante el inicio de los servicios del sistema operativo.

Neither the enviroment variable CONDOR_CONFIG,
/etc/condor, ~condor/ contain a condor_config source.
Either set CONDOR_CONFIG to point to a valid config source,
or put a “condor_config” file /etc/condor or ~condor/

Explicación.

Condor durante su inicio automático no está encontrando su configuración básica.

Solución.

Especifique cual es el archivo de configuración básica de Condor mediante la especificación de la variable de ambiente CONDOR_CONFIG o mediante la ubicación (a través de un enlace) del archivo, ya sea en /etc/condor (ubicación especificada con el parámetro –local-dir durante la instalación) o en ~condor/.

Para este caso, el problema se resolverá mediante la segunda opción: creando un enlace al archivo de configuración desde ~condor/.

# ln -s /opt/condor/current/etc/condor_config ~condor/condor_config

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de No es posible encontrar condor_config durante el inicio automático.
Aug 11

Problema.

Condor no inicia en un nodo específico.  En sus logs se encuentran mensajes como los siguientes.

CollectorLog

08/11 21:59:35 AUTHENTICATE: handshake failed!
08/11 21:59:35 ERROR: SECMAN:2004:Failed to create security session to <192.168.1.230:9180> with TCP.|AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD

MasterLog

08/11 22:00:36 DC_AUTHENTICATE: authenticate failed: AUTHENTICATE:1002:Failure performing handshake|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
08/11 22:00:36 condor_write(): Socket closed when trying to write 297 bytes to <192.168.1.230:45838>, fd is 10
08/11 22:00:36 Buf::write(): condor_write() failed
08/11 22:00:36 SECMAN: Error sending response classad!
08/11 22:00:36 error: SEC_PASSWORD_FILE must be owned by Condor’s real uid

Explicación.

El archivo donde se almacena la contraseña del cluster para la autenticación basada en las mismas, tiene un propietario o unos permisos incorrectos.

Solución.

Identificar la ubicación del archivo de contraseñas.

# condor_config_val SEC_PASSWORD_FILE

/etc/condor/condor_credential

Verificar sus permisos y propietario.

# ls -l /etc/condor/condor_credential

-rw-r–r– 1 condor root 256 Aug 11 21:47 /etc/condor/condor_credential

Corregir sus permisos y propietario.

# chown root:root /etc/condor/condor_credential

# chmod 600 /etc/condor/condor_credential

# ls -l /etc/condor/condor_credential

-rw——- 1 root root 256 Aug 11 21:47 /etc/condor/condor_credential

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de SEC_PASSWORD_FILE must be owned by Condor’s real uid.
Aug 11

Problema.

Al intentar enlazar un programa en C/C++ con las librerías de Condor mediante condor_compile se obtiene el siguiente mensaje de error.

$ condor_compile gcc test.c -o test

LINKING FOR CONDOR : /usr/bin/ld -L/opt/condor/current/lib -Bstatic –eh-frame-hdr -m elf_x86_64 –hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test /opt/condor/current/lib/condor_rt0.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginT.o -L/opt/condor/current/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccawslhh.o /opt/condor/current/lib/libcondorzsyscall.a /opt/condor/current/lib/libcondor_z.a /opt/condor/current/lib/libcomp_libstdc++.a /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a –as-needed –no-as-needed -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c -lcondor_nss_files -lcondor_nss_dns -lcondor_resolv -lcondor_c /opt/condor/current/lib/libcomp_libgcc.a /opt/condor/current/lib/libcomp_libgcc_eh.a –as-needed –no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: skipping incompatible /opt/condor/current/lib/libcondor_c.a when searching for -lcondor_c
/usr/bin/ld: cannot find -lcondor_c

collect2: ld returned 1 exit status

Explicación.

La arquitectura de la distribución de Condor no coincide con la de la máquina en la cual se instaló.

Solución.

Identifique la arquitectura de la máquina en la cual se está instalando Condor de la siguiente manera.

# uname -i

x86_64

Verifique que esta coincida con la arquitectura del paquete de Condor que se descargó del sitio web.

condor-*-linux-x86-rhel5-dynamic.tar.gz
condor-*-linux-x86_64-rhel5-dynamic.tar.gz

Reinstale Condor con la arquitectura correcta.

Tagged with:



En August 11 de 2010, Jorge Iván Meza Martínez escribió acerca de Instalación de Condor en una arquitectura incorrecta.
Jul 12

Introducción.

Después de realizado el proceso de instalación de SUN Java en los diferentes nodos del cluster la configuración de Java debería funcionar inmediatamente sin embargo al verificar la lista de cuales nodos soportan trabajos Java aparece vacía.

# condor_status -java

Realizar verificaciones (1).

Se verifican los valores básicos de la configuración de Java y su correspondencia con la realidad del cluster.

Ubicación de Java.

# condor_config_val JAVA

/usr/bin/java

# ls -l /usr/bin/java

lrwxrwxrwx 1 root root 26 Jun 13 11:43 /usr/bin/java -> /usr/java/default/bin/java

# /usr/bin/java -version

java version “1.6.0_20″
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

Tamaño máximo de la memoria del heap.

# condor_config_val JAVA_MAXHEAP_ARGUMENT

-Xmx1024m

Diagnosticar el problema.

# condor_starter -classad

CondorVersion = “$CondorVersion: 7.4.2 Mar 29 2010 BuildID: 227044 $”
IsDaemonCore = True
HasFileTransfer = True
HasPerFileEncryption = True
HasReconnect = True
HasMPI = True
HasTDP = True
HasJobDeferral = True
HasJICLocalConfig = True
HasJICLocalStdin = True
Invalid maximum heap size: -Xmx1024m246m
Could not create the Java virtual machine.

HasVM = True

Según se interpreta lo anterior, Condor está detectando correctamente la ubicación de la máquina virtual de Java, sin embargo está fallando en su creación debido a un valor inválido en la cantidad máxima de memoria para el heap.  Según el manual de Condor esto puede estar sucediendo cuando se utiliza la máquina virtual de SUN Microsystems.

One identified difficulty occurs when the machine has a large quantity of physical RAM, and this quantity exceeds the Java limitations. This is a known problem for the Sun JVM. Condor appends the maximum amount of system RAM to the Java Maxheap Argument, and sometimes this value is larger than the JVM allows. The end result is that Condor believes that the JVM on the machine is faulty, resulting in nothing showing up as a result of executing the command condor_status -java.

Implementar la solución.

Reemplazar la definión de la variable JAVA_MAXHEAP_ARGUMENT con las siguientes variables.

# vi /opt/condor/condor/etc/condor_config.local

# First set JAVA_MAXHEAP_ARGUMENT to null, to disable the default of max RAM
JAVA_MAXHEAP_ARGUMENT =
# Now set the argument with the Sun-specific maximum allowable value
JAVA_EXTRA_ARGUMENTS = -Xmx1024m

Ajuste según sus requerimientos, el valor de memoria (MB) a asignársele al heap en el parámetro JAVA_EXTRA_ARGUMENTS.

# condor_reconfig c-head c-wn1 c-wn2

Sent “Reconfig” command to master c-head.jorgeivanmeza.com
Sent “Reconfig” command to master c-wn1.jorgeivanmeza.com
Sent “Reconfig” command to master c-wn2.jorgeivanmeza.com

Realizar verificaciones (2).

Estado de la configuración de Java.

# condor_starter -classad

CondorVersion = “$CondorVersion: 7.4.2 Mar 29 2010 BuildID: 227044 $”
IsDaemonCore = True
HasFileTransfer = True
HasPerFileEncryption = True
HasReconnect = True
HasMPI = True
HasTDP = True
HasJobDeferral = True
HasJICLocalConfig = True
HasJICLocalStdin = True
JavaVendor = “Sun Microsystems Inc.”
JavaVersion = “1.6.0_20″
JavaSpecificationVersion = “1.6″
JavaMFlops = 495.500641
HasJava = True
HasVM = True

Nodos con soporte para Java.

# condor_status -java

Name               JavaVendor Ver    State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     0.230   246  0+00:00:04
c-wn2.jorgeivanmez
Sun Micros 1.6.0_ Unclaimed Idle     0.080   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     2     0       0         2       0          0        0

Total            2     0       0         2       0          0        0

Enlaces.

Tagged with:



En July 12 de 2010, Jorge Iván Meza Martínez escribió acerca de C-Cluster: reparando el soporte de SUN Java en Condor.