Bonjour je rencontre actuellement un soucis lorsque je tente de lancer un script sur le cluster.
L'un de mes scripts est bloqué et affiche CG comme statuts et il n'est pas scancelable :
17154376 long bwa_oran thboyer CG 0:10 1 cpu-node-19
les autres ne se lancent tout simplement pas, aucun retour de la console même pas de création des fichiers erreur ou output.
Voici le script en question :
#!/bin/bash
#SBATCH -p long
#SBATCH --job-name=bwa_oran
#SBATCH --cpus-per-task=30
#SBATCH --mem 100GB
#SBATCH -o /shared/projects/oran_lake_meta/results/final/bwa/bwa_metaspades_6_12/bwa_metaSpades_6_12/slurm_bwa.%N.%j.out
#SBATCH -e /shared/projects/oran_lake_meta/results/final/bwa/bwa_metaspades_6_12/bwa_metaSpades_6_12/slurm_bwa.%N.%j.err
module load bwa/0.7.17
module load samtools/1.10
##Mapping pour l'assemblage de metaSpades dont les contigs en défauts ont été viré
path_data=/shared/projects/oran_lake_meta/results/seqkit/
path_read=/shared/projects/oran_lake_meta/results/trimmomatic/120221_trimmomatic
cd /shared/projects/oran_lake_meta/results/final/bwa/bwa_metaspades_6_12
##Creation de l'index
bwa index -a bwtsw ${path_data}/contigs_validate_6_12_cov.fasta
#alignement
bwa mem ${path_data}/contigs_validate_6_12_cov.fasta ${path_read}/6-12-combined_1P.fq.gz ${path_read}/6-12-combined_2P.fq.gz > mapping_6_12.sam
samtools view -S -b mapping_6_12.sam > mapping_6_12.bam
samtools flagstat mapping_6_12.bam
module unload bwa/0.7.17
module unload samtools/1.10
Savez vous si le problème vient de mon script ou du cluster ?
Le status "CG" corresponds à "COMPLETING".
Le job est terminé (l'exécution du script bash ou de la commande est finit, avec succès ou en échec) mais une dernière étape ("completing") est réalisé avant de libérer le ressources (processus nettoyés, epilog, etc).
Cette dernière étape est réalisé en quelques secondes mais il peut arriver que cela coince.
Il n'y a rien à faire si ce n'est attendre que cela se termine (ou l'intervention d'un admin).
Merci beaucoup pour votre réponse, le problème semblait en effet résolu... malheureusement il est réapparu mais avec un autre script cette fois ci.
Pour être plus précis, lorsque je soumets mon job avec sbatch, ici sur la partition long, celui ci se mets en PD (car il n'y a pas de place actuellement) puis un petit peu après passe en CG sans n'avoir rien exécuté, pour ensuite s'arrêter (comme vous me l'aviez expliquer dans votre post précédent).
J'en ai lancé plusieurs en même temps pour que vous visualisiez mieux :
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17343784 long squeeze_ thboyer CG 0:01 1 cpu-node-24
17343786 long squeeze_ thboyer PD 0:00 1 (Resources)
17343788 long squeeze_ thboyer PD 0:00 1 (Priority)
Comme cela fait deux fois que ça arrive avec deux scripts différents, je me demande si ce problème vient de moi ou non.
Voici le script squeezemeta_1_5.sh que je tente de lancer :
De ce que je voit, les jobs échouent (failed) immédiatement après le lancement.
Ce n'est pas dû au cluster ou autre mais bien au script ou au logiciel (squeezemeta).
# Par exemple pour le job 17343786
$ sacct -j 17343786
JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
17343786 squeeze_m+ long oran_lake+ 40 FAILED 1:0
17343786.ba+ batch oran_lake+ 40 FAILED 1:0
Il faut du coup analyser le fichier de sortie que vous avez indiqué, à savoir: /shared/projects/oran_lake_meta/results/squeezemeta/final/slurm_sqm_1_5.%N.%j.out /shared/projects/oran_lake_meta/results/squeezemeta/final/slurm_sqm_1_5.%N.%j.err
Attention ! le répertoire où les sorties sont écrites doit exister (/shared/projects/oran_lake_meta/results/squeezemeta/final/).
Problème résolu... il venait en effet du chemin d'écriture des outputs pour lequel j'avais inversé final et squeezemeta... Il ne pouvait donc rien écrire et plantait...
Merci beaucoup pour votre aide, je serais plus vigilant la prochaine fois
