| 55 | |
| 56 | |
| 57 | == Cas asynchrone - avec post-traitement == |
| 58 | |
| 59 | Il y a de nombreux cas ou le script de soumission doit reprendre la main après l'exécution du code de calcul. |
| 60 | Cependant, il faut savoir que le shell ne gère les signaux qu'entre deux instructions, |
| 61 | ou lors d'instruction bloquante interne au shell (par exemple {{{wait}}}). |
| 62 | |
| 63 | L'exemple suivant par exemple ne fonctionne pas |
| 64 | car le script exécutera le code dans {{{trap}}} qu'une fois le code {{{mycode}}} finit, |
| 65 | donc en pratique jamais car le code dure plus de 24h. |
| 66 | Au final, au bout de 24, {{{OAR}}} fera un {{{kill}}} violent du code... |
| 67 | {{{ |
| 68 | #!/bin/bash |
| 69 | |
| 70 | #OAR -n MYCODE |
| 71 | #OAR -t idempotent |
| 72 | #OAR --checkpoint 600 |
| 73 | #OAR -l /core=1,walltime=24:00:00 |
| 74 | |
| 75 | # Signal child retransmit |
| 76 | trap 'kill -USR2 $(jobs -p)' USR2 |
| 77 | |
| 78 | |
| 79 | # Load environment |
| 80 | . /etc/profile |
| 81 | |
| 82 | module load intel/2011.7 |
| 83 | |
| 84 | |
| 85 | # Pretreatment possible here |
| 86 | |
| 87 | |
| 88 | # Start / give the hand to the code |
| 89 | ./mycode |
| 90 | |
| 91 | |
| 92 | # Post-treatment possible here |
| 93 | |
| 94 | }}} |
| 95 | |
| 96 | Une solution est de lancer le code en asynchrone |
| 97 | afin que le script de soumission reprenne le plus vite possible la main. |
| 98 | Cependant, il doit quand même attendre la fin du code avant de faire l'étape de post-traitement. |
| 99 | Voici une solution fonctionnelle à ces impératifs |
| 100 | |
| 101 | {{{ |
| 102 | #!/bin/bash |
| 103 | |
| 104 | #OAR -n MYCODE |
| 105 | #OAR -t idempotent |
| 106 | #OAR --checkpoint 600 |
| 107 | #OAR -l /core=1,walltime=24:00:00 |
| 108 | |
| 109 | # Signal child retransmit |
| 110 | trap 'kill -USR2 $(jobs -p)' USR2 |
| 111 | |
| 112 | |
| 113 | # Load environment |
| 114 | . /etc/profile |
| 115 | |
| 116 | module load intel/2011.7 |
| 117 | |
| 118 | |
| 119 | # Pretreatment possible here |
| 120 | |
| 121 | |
| 122 | # Launch the code and take back the hand (asynchrone) |
| 123 | ./mycode & |
| 124 | |
| 125 | # Wait for the end of the code |
| 126 | while [ $(jobs -p | wc -l) -gt 0 ] |
| 127 | do |
| 128 | wait |
| 129 | done |
| 130 | |
| 131 | # Post-treatment possible here |
| 132 | |
| 133 | }}} |
| 134 | |
| 135 | La boucle while est très importante |
| 136 | car le code peux finir suite à la réception d'un signal |
| 137 | mais aussi naturellement lorsqu'il a enfin finit son traitement global. |
| 138 | Les deux cas doivent être géré. |
| 139 | Or la commande interne '''{{{wait}}}''' attends la '''fin du calcul''' |
| 140 | ou la '''réception d'un signal'''. |
| 141 | |
| 142 | Une fois le signal reçu, la commande {{{trap}}} retransmet le signal au code, |
| 143 | et le script de soumission repars dans la boucle {{{while}}} |
| 144 | afin d'attendre la fin réelle du code. |
| 145 | Sans cette boucle, |
| 146 | il passerait de suite sur la phase de post-traitement |
| 147 | et se terminerait en laissant {{{OAR}}} tuer sauvagement le code dans sa phase terminale... |