Cuando programo un trabajo con 'at', se le asigna una identificación, a saber:
trabajo 44 en 2014-01-28 17:30
Cuando se ejecute ese trabajo, me gustaría obtener esa identificación desde dentro. Esto está en Centos, FWIW. He establecido que ninguna variable de entorno contiene el ID. Cuando se ejecuta el código Perl en ese trabajo, me gustaría poder imprimir la identificación del trabajo (44 en este ejemplo).
Sí, sé que atq muestra un = junto a los trabajos que se están ejecutando, pero puede haber más de uno a la vez.
Podría hacer algo como pasar un argumento único al trabajo al programarlo, capturar la ID, guardar eso y el argumento en un archivo en algún lugar, leer eso del trabajo. Es mucho trabajo al que preferiría no ir si no tengo que hacerlo, y parece que esto debería ser simple, pero me estoy quedando en blanco.
Lo que sigue se descifra leyendo las fuentes de at-3.14. La forma en que se coloca la identificación del trabajo y la hora en que se ejecuta en el nombre del archivo debería ser similar para cualquier versión, pero no lo he comprobado.
Para empezar, codifica la identificación del trabajo y la hora en que se debe ejecutar un trabajo en particular en el nombre del archivo que describe un trabajo. El nombre del archivo tiene el formato aJJJJJTTTTTTTT , donde JJJJJ es una cadena hexadecimal de 5 caracteres, la identificación del trabajo, y TTTTTTTT es una cadena hexadecimal de 8 caracteres, la hora en que se debe ejecutar el trabajo. El tiempo se almacena como segundos a partir de la época.
Los trabajos at se ejecutan alimentando un archivo de descripción del trabajo como entrada estándar a sh -c . Afortunadamente, el kernel de Linux proporciona un enlace simbólico, /proc/self/fd/0 , que apuntará a la entrada estándar del proceso que se está ejecutando actualmente (juegue con ls -l /proc/self/fd/0 en caso de que necesite asegúrense de que efectivamente es así).
Un archivo que describe un trabajo se ha eliminado en el momento en que se ejecuta un trabajo. Sin embargo, el archivo todavía está disponible para el núcleo porque se duplicó con dup(2) antes de usarse como entrada estándar para un trabajo. Entonces, en realidad estamos resolviendo un enlace simbólico a un nombre de archivo que ya no es visible. En el script perl al final, debemos tener esto en cuenta, ya que readlink devolverá algo como /foo/bar/baz (deleted) en lugar de /foo/bar/baz . Y estamos interesados solo en el nombre del archivo que tiene toda la información que necesitamos.
La razón por la cual el enlace simbólico apunta a un archivo eliminado es porque at daemon desvincula el original antes de ejecutar el trabajo. La desvinculación se realiza solo después de crear una copia, un enlace físico, que comienza con = en lugar de a . Con esto, el demonio at intenta asegurarse de que solo habrá una copia de un trabajo en ejecución: el demonio no execle(2) , es decir. se rescatará, en caso de que el link(2) falle. Debido a que el archivo original ha estado sujeto a open(2) y dup(2) el inodo todavía está allí para que lo use el kernel porque todavía tiene enlaces duros que apuntan a él.
Después de una introducción bastante larga y posiblemente confusa, aquí está cómo ponerlo todo junto:
#!/usr/bin/perl use strict; use warnings; my $job_file = readlink("/proc/self/fd/0"); if (index($job_file, " ") > 0) { $job_file = substr($job_file, 0, index($job_file, " ") - 1); } my $tmp = substr($job_file, rindex($job_file, "/") + 1); $tmp =~ s/^a([0-9a-f]{5})[0-9a-f]+/$1/; my $job_id = hex($tmp); if ($job_id > 0) { printf("My AT job id is %d.\n", $job_id); } # end of file.