J’ai résolu mon problème, mais uniquement dans le cas d’une fonction “réversible”, et qui commute avec le script sbatch.
Un peu de notations :
[ul][li]f_cancel, la fonction que l’on veut appeler lors de l’annulation d’une tâche par scancel ;[/li]
[li]f_run, la fonction coeur, idéalement le seul contenu du script s_run ;[/li]
[li]f_uncancel, le fonction “inverse” de f_cancel.[/li][/ul]
[ul][li]PD, l’état “Pending” d’une tâche en attente de ressource disponibles ;[/li]
[li]R, l’état “Running” ;[/li]
[li]CL, l’état “Cancelling” ;[/li]
[li]CP, l’état “Completed”.[/li][/ul]
En utilisant cette notaion :
_____________________________
| ÉTAT |
| Fonction exécutée lors |
| de l'arrivée dans cet état |
|_____________________________|
Le schéma d’exécution que je voulais :
[code] ______
| PD |------ SIGTERM ----| (1)
|| | __________
| |------> | CL |
v | | f_cancel |
_______ | ||
| R |----- SIGTERM ----| (2)
| f_run |
|___|
|
v
| CP |
|______|[/code]
Avec l’exécution de f_cancel quand la tâche arrive dans l’état CL.
Malheureusement, Si la tâche est dans l’état Pending, il n’y a pas de processus pour capturer un SIGTERM, donc pas d’accès à l’état Cancelling. La tâche est simplement supprimée de la file d’attente. (La branche 2 fonctionne, mais pas la 1).
Si f_cancel est inversible et commute avec f_run (j’utilise des termes pompeux, mais la définition mathématique correspond exactement à mes besoins), il y a une solution.
[code] ___________
| PD |
| f_cancel |
|____________|
|
v
| R |----- SIGTERM ----> | CL |
| f_run | | |
|| |___|
|
v
| CP |
| f_uncancel |
|______________|[/code]
f_cancel à l’état PD n’est pas très rigoureux. f_cancel est plutôt appelée lors de la soumission de la tâche. La tâche passe ensuite en état Pending.
Je suis concient que des automates auraient été plus clairs que ces graphes pourris… Mais c’est chiant à faire !
A+
Moi
