Estado de los trabajos enviados. condor_q

Podemos obtener información acerca de nuestros trabajos con el comando condor_q:

[adrians@trevina ~]$ condor_submit myjob.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 1.

[adrians@trevina ~]$ condor_q


-- Submitter: trevina.iac.es : <161.72.81.178:1085> : trevina.iac.es
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
   1.0   adrians         7/13 12:37   0+00:00:00 I  0   0.0  myprog Example.1.0

1 jobs; 1 idle, 0 running, 0 held

Por defecto, este comando nos mostrará información de los trabajos que hemos enviado desde la máquina donde se ejecuta, en el ejemplo sería ``trevina''. La información que aparece en la salida sería:

• El ID es el identificador del trabajo y está formado por dos números:
  • El número antes del punto representa el ``cluster''. Un ``cluster'' es el conjunto de trabajos creado en un envío. Podemos ver un ejemplo en la salida del comando ``condor_submit''.
  • El número después del punto representa el trabajo dentro del cluster, como en el ejemplo solo creamos uno, será el trabajo 0. Trabajos sucesivos en el mismo cluster se nombrarían como 1.1, 1.2, ....
• El usuario que envío los trabajos.
• La fecha del envío.
• El tiempo de ejecución, en el formato: Días+HH:MM:SS.
• El estado actual del trabajo. Algunos valores posibles son:

  I:

  No se está ejecutando porque aun no se le ha asignado ninguna máquina (IDLE).

  R:

  Ejecutándose actualmente (RUNNING).

  H:

  El trabajo no se está ejecutando por deseo del propietario (HOLD). Ver el comando condor_hold, condor_release o la sección Managing a Job del manual de Condor.

• La prioridad del trabajo que ha especificado el usuario. Ver comando condor_prio o la sección Managing a Job del manual de Condor.
• El tamaño de la imagen del trabajo en megabytes.
• Y por último, el nombre del ejecutable.

En el caso de que un trabajo no se esté ejecutando, este comando también nos permite conocer el motivo gracias a la opción -analyze. Por ejemplo:

[adrians@trevina ~]$ condor_submit myjob.submit 
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 1.

[adrians@trevina ~]$ condor_q -analyze


-- Submitter: trevina.iac.es : <161.72.81.178:39869> : trevina.iac.es
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD               
---
001.000:  Run analysis summary.  Of 187 machines,
    187 are rejected by your job's requirements
      0 reject your job because of their own requirements
      0 match, but are serving users with a better priority in the pool
      0 match, but prefer another specific job despite its worse user-priority
      0 match, but will not currently preempt their existing job
      0 are available to run your job
        No successful match recorded.
        Last failed match: Thu Sep 16 12:38:09 2004
        Reason for last match failure: no match found

WARNING:  Be advised:
   No resources matched request's constraints
   Check the Requirements expression below:

Requirements = ((Memory > 2147483647)) && (Arch == "INTEL") &&
(OpSys == "LINUX") && (Disk >= DiskUsage) &&
(TARGET.FileSystemDomain == MY.FileSystemDomain)

En el ejemplo podemos ver como el trabajo 1.0 tiene problemas para ejecutarse: nuestros requisitos (Requirements) han desechado 187 máquinas de las 187 candidatas. Además, condor_q nos sugiere que revisemos dicha expresión y nos la muestra en su salida (en el ejemplo vemos como el límite mínimo de memoria RAM es excesivo).

Para más información puedes visitar la página del manual de condor_q , la secciónManaging a Job del manual de Condor.