```bash module add io-local slurm-user-tools # afficher les détails de l'account dédié show_detail_account_association <account_name> # afficher les ressources consommées actuellement squeue_account_count_running_rss <account_name> ```
sbatch: error:…Reason=AssocGrpMemLimit ou Reason=AssocGrpCpuLimitPour y accéder vous pouvez vous y connecter avec votre login et mot de passe du cluster
bien lire ces pages :
infos sur la migration de muse vers IO : https://docs.meso.umontpellier.fr/fr/HPC/migration-muse2io
toutes les spécificités de IO : https://docs.meso.umontpellier.fr/fr/HPC/CLUSTER/cluster-io-specifications
R : io-login.meso.umontpellier.fr
Les problèmes connus et non résolus dans cette phase de tests sont indiqués dans la page des spécifications du cluster : https://docs.meso.umontpellier.fr/fr/HPC/CLUSTER/cluster-io-specifications#_probl%C3%A8mes_connus
R : Lors de la migration, les chemins vers les scratchs respectifs de l’ancien cluster (le répertoire "scratch") et du nouveau cluster ont été mis à disposition simultanément. Ainsi l’ancien dossier "scratch" est toujours visible sur le nouveau cluster car le homedirectory de l’ancien cluster est strictement le même que sur le nouveau, donc le lien vers l’ancien est présent, mais il ne doit plus être utilisé.
R : Oui, c’est une des grandes nouveautés ! Il y a maintenant 2 types de scratch :
le scratch personnel tel que connu sur le cluster muse. Ce répertoire de scratch personnel qui s’appelait simplement "scratch" s’appelle maintenant "scratch_NomDeLogin" où NomDeLogin est le nom de votre compte
le ou les scratchs de groupe. Ces scratch vous permettent de collaborer dans votre groupe sur le calcul. Ça évite notamment les copies des mêmes données dans les scratch de chaque utilisateur du groupe. Attention : Si vous mettez des données dans ces scratchs de groupe, ils seront alors visibles par toutes les personnes du groupe.
R : io-login.meso.umontpellier.fr
Il faut privilégier cette adresse aux adresses directes ou noms des noeuds de login qui peuvent évoluer dans le temps.
R : Vérifiez l’adresse et votre login. Assurez-vous d’être sur le VPN ou le réseau autorisé si nécessaire (certains clusters ne sont accessibles qu’institutionnellement). Si le message d’erreur est "Connection timed out", c’est un blocage réseau (VPN probablement requis). Si c’est "Access denied" ou "Permission denied", vérifiez login/mot de passe. En cas d’authentification par clé, assurez-vous que votre clé privée est chargée (ssh-agent) et que votre clé publique a été communiquée aux admins. Enfin, assurez-vous que vous utilisez le bon port (22 par défaut) et protocole SSH (utilisez un client adéquat comme PuTTY ou OpenSSH).
Si vous pouviez vous connecter auparavant et ne pouvez plus depuis quelques jours, votre compte a certainement expiré. Merci de créer un ticket ici en rajoutant toutes les informations qui peuvent nous être utile, comme votre groupe, votre responsable hierarchique, un correspondant du mesocentre, etc.
R : Plusieurs causes possibles :
Vérifiez l’adresse du serveur et le port. Pour ISDM cluster, c’est io-login.meso.umontpellier.fr port 22. Une erreur de frappe (ex : .com au lieu de .fr) peut faire échouer la connexion.
Assurez-vous d’être connecté à Internet. Si vous êtes hors de l’institution, peut-être faut-il établir un VPN pour accéder au réseau interne du cluster (consultez la documentation locale, certains clusters sont derrière un VPN ou une passerelle de sécurité).
Si vous avez un message "No route to host" ou "Connection timed out", c’est un problème réseau (adresse incorrecte, serveur down, pare-feu bloquant). Si c’est "Connection refused", le serveur est joignable mais le service SSH n’accepte pas la connexion – cela peut arriver si vous spécifiez un mauvais port ou si le serveur SSH est temporairement indisponible.
Essayez de pinguer le serveur (ping io-login.meso.umontpellier.fr). S’il ne répond pas du tout, voyez si vous avez les bons accès réseau. En dernier recours, contactez l’administrateur pour vérifier que le cluster est en ligne et que votre IP n’est pas bloquée.
R : Cela indique que l’authentification échoue. Causes communes :
Mot de passe incorrect : Assurez-vous de taper le bon mot de passe, en respectant les majuscules/minuscules. Attention à la disposition du clavier en mode console (par ex, sur certains claviers azerty, les chiffres nécessitent Maj). Si vous avez trop essayé, votre compte peut être temporairement bloqué (au bout de X tentatives, l’IP (votre adresse de connexion) est bannie pour quelques minutes). Patientez et réessayez calmement.
Compte expiré ou verrouillé : Si vous êtes un nouvel utilisateur, assurez-vous que votre compte a été créé et activé. Si votre compte a expiré (par ex. stage terminé, compte désactivé), vous ne pourrez plus vous connecter. En cas de doute, contactez l’équipe support pour vérifier l’état du compte.
Domaine incorrect : le cluster a plusieurs frontales ou noeud de login. Assurez-vous de vous connecter avec username@io-login.meso.umontpellier.fr. Si vous mettez un mauvais nom d’utilisateur, vous aurez "Permission denied" car cet utilisateur n’existe pas ou n’a pas accès.
R : Lors de la première connexion, SSH vous montre l’empreinte de la clé du serveur et vous demande de confirmer (en tapant "yes"). C’est normal et il faut accepter si vous vous attendez à vous connecter à ce serveur. Cela permet de s’assurer que vous n’êtes pas victime d’un usurpateur. Une fois accepté, la clé du serveur est ajoutée à votre fichier known_hosts et les prochaines connexions ne redemanderont pas.
Si en revanche vous voyez un message du type "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" lors d’une connexion ultérieure, n’entrez pas votre mot de passe tout de suite. Cela signifie que la clé du serveur est différente de la dernière fois (le serveur a peut-être été réinstallé, ou vous êtes victime d’une attaque de type man-in-the-middle). Dans ce cas, contactez l’équipe support pour vérifier si la clé a changé volontairement. Si oui, on vous donnera la nouvelle empreinte à vérifier et vous pourrez l’accepter (en supprimant l’ancienne entrée de known_hosts). Ne faites cela que si vous êtes sûr de la provenance du changement.
sbatch: error:…R : Plusieurs possibilités :
sbatch: error: Batch job submission failed: Invalid qos specification
Si vous êtes un utilisateur d’un account dedicated@*, dans ce cas, pensez à préciser la partition -p cpu-dedicated à la soumission. En effet, la partition par défaut est cpu-ondemand.
Reason=AssocGrpMemLimit ou Reason=AssocGrpCpuLimitVotre account est limité en ressources CPU et mémoire. Pour vérifier ses valeurs, vous pouvez utiliser :
```bash module add io-local slurm-user-tools # afficher les détails de l'account dédié show_detail_account_association <account_name> # afficher les ressources consommées actuellement squeue_account_count_running_rss <account_name> ```
R : Plusieurs possibilités :
Pas assez de ressources libres pour lancer votre job (il attend que d’autres jobs se terminent).
Vous avez demandé un temps d’exécution qui ne correspond pas à la partition ou la QOS souhaitée (voir aussi le temps par défaut).
Par exemple, avec un account ondemand@* sans QOS spécifié héritera par défaut de ondemand-short avec un temps limite par job de 1h. Sans option --time, Slurm cherchera à mettre votre job sur la partition cpu-ondemand avec un temps par défaut qui est de 7 jours ! Le résultat est une erreur de type QOSMaxWallDurationPerJobLimit. Nous allons certainement aligner ces valeurs pour éviter ce type d’erreur, mais il y aura dans tous les cas une durée par défaut. Il faut donc ne jamais oublier le --time.
AssocMaxWallDurationPerJobLimit correspond à la même erreur, mais au niveau de votre account. Dans ce cas, pensez à utiliser soit un autre account si possible ou une autre QOS (voir account-et-qos et rajoutez un --time si ce n’est pas déjà le cas)
Vous avez demandé une partition particulière moins prioritaire ou très chargée.
Vous avez demandé trop de ressources (ex: tous les nœuds) ce qui nécessite d’attendre un créneau. Utilisez squeue -j <jobid> -o "%r" pour voir la raison : Resources ⇒ en attente de ressources, Priority ⇒ votre job attend son tour (priorité plus basse). Patientez ou modifiez votre requête (ex: réduire le temps ou le nombre de nœuds peut le faire démarrer plus vite). Si la raison est PartitionTimeLimit ou autre, vérifiez que vous respectez les contraintes de la partition. En cas de doute, contactez un admin pour voir si votre job est bloqué pour une raison spécifique.
La liste des raisons est disponible ici : https://slurm.schedmd.com/job_reason_codes.html
R : Un job PENDING signifie qu’il attend d’être lancé.
En pratique, si votre job reste PENDING plus longtemps que d’habitude sur ce cluster, inspectez squeue -O reason ou scontrol show job <jobid> pour avoir plus de détails. Vous pouvez aussi regarder sinfo pour voir l’état des partitions.
Les raisons principales sont :
Pas assez de ressources disponibles : Votre job attend qu’un nœud se libère avec les ressources demandées. Vous pouvez vérifier la raison avec squeue -j <jobid> -O reason ou en regardant la colonne NODELIST(REASON) de squeue. Si c’est marqué "Resources", c’est juste en attente de ressources. Patience !
Priorité : Si la raison indique "Priority" : cela signifie qu’il y a d’autres jobs devant vous (le scheduler Slurm attribue une priorité à chaque job en fonction de divers facteurs). Vous devez attendre votre tour. Certains clusters ont des quotas ou des fenêtres d’exécution – par exemple, pas plus de X jobs simultanés par utilisateur, ou un système de fair-share qui peut retarder vos jobs si vous avez déjà consommé beaucoup de temps de calcul récemment.
Partition fermée ou limites : Si la raison est "PartitionDown", "QoSMaxXX", "AssocGrpCpuLimit", etc., il peut y avoir une contrainte particulière :
PartitionDown/DRAINED : la file de calcul est fermée (maintenance, panne de nœud).
QoS ou Assoc limits : vous avez peut-être atteint une limite (ex : nombre max de CPU utilisables à la fois, ou quota d’heures). Dans ce cas, soit attendre le reset des quotas, soit demander aux admins si c’est normal.
Demande trop grosse : Si vous avez demandé un nombre de ressources très élevé (ex: 1000 cœurs) et que le cluster est modeste, le scheduler ne trouvera jamais un créneau pour vous. Il vaut mieux réduire la demande ou découper en plusieurs jobs.
Si vous êtes pressé et que c’est possible, utilisez une partition spéciale si disponible (par ex. une partition short pour les jobs courts, souvent moins encombrée). Sinon, hélas, attendre.
R : Slurm a mis fin à votre job parce qu’il a dépassé une limite que vous aviez spécifiée (ou une limite par défaut) :
Time Limit Exceeded : le job a tourné plus longtemps que le temps alloué (#SBATCH --time). Par exemple, vous aviez demandé 1 heure, mais l’exécution n’était pas finie et a atteint 1h, alors Slurm l’a tuée.
Solution : estimer mieux le temps nécessaire et redemander un job avec plus de temps (ex: --time=2:00:00 pour 2h).
Surveillez aussi votre code : s’il prend beaucoup plus de temps qu’attendu, y a-t-il une inefficacité ? Parfois, on commence par tester sur un petit cas pour estimer la durée sur un gros cas. Si le job a quasiment fini (par ex. 99% complet) quand il est tué, vous pouvez relancer en prolongeant un peu le temps.
OOM (Out Of Memory) ou segfault lié à la mémoire : cela signifie que votre programme a demandé plus de mémoire RAM que disponible. Sur Slurm, si vous n’avez pas explicitement demandé la mémoire (--mem ou --mem-per-cpu), il y a une valeur par défaut de 2 Go par CPU. Si votre job dépasse, le noyau Linux peut le "tuer" (processus terminé avec code 9) – d’où le message dans le .err ou un signal KILL.
Solution : demander plus de mémoire dans votre script Slurm (#SBATCH --mem=16G par ex. pour 16 Go). Veillez à être raisonnable : n’allouez pas 200 Go si vous n’en avez besoin que de 20, par courtoisie pour les autres et pour ne pas attendre inutilement que 200Go de RAM se libèrent. Utilisez sacct -j <jobid> -o MaxRSS pour voir la mémoire qu’il a tentée d’utiliser avant d’être tué. Si la mémoire demandée dépasse ce qu’un nœud peut fournir, il faut repenser votre tâche (diviser le job en sous-tâches, optimiser la mémoire, etc.).
Autres erreurs :
Node failure si le nœud a planté : rare, dans ce cas Slurm relance souvent le job sur un autre nœud automatiquement).
Erreur d’application : Parfois le job est "COMPLETED" pour Slurm mais en fait votre programme a planté (exemple : exit code non égal à zéro, "Array out of bounds" ou "File not found", … ). Ce n’est pas Slurm mais votre programme qui a planté. Il faut alors déboguer le programme lui-même ! Vérifiez les fichiers de sortie .out et .err. Voyez les messages d’erreur de votre logiciel. Corrigez le bug dans votre code ou la façon dont vous lancez le programme.
R : Cela signifie qu’une commande appelée dans votre script de job n’existe pas dans l’environnement d’exécution. Par exemple python: command not found veut dire que Python n’est pas dans le PATH au moment où le job tourne. Solution : charger les modules nécessaires dans le script (ex: ajoutez module load python/3.8 en début de script) ou activer votre env conda à l’intérieur du job script. Un autre exemple : mpirun: not found – peut-être devriez-vous utiliser srun au lieu de mpirun avec Slurm, ou charger le module MPI approprié. En général, assurez-vous que votre script de job initialise le même environnement logiciel que vous utilisez interactivement.
R : Quelques astuces pour garder un œil sur vos jobs en cours :
Utilisez squeue -u <user> pour voir le statut (PENDING/RUNNING) et le temps CPU consommé (colonne TIME). Cela vous dit si le job tourne toujours et depuis combien de temps, mais pas son avancement interne.
Si votre job produit une sortie périodique (par exemple, écrit dans un fichier log ou dans son fichier de sortie standard régulièrement), vous pouvez lire ce fichier même pendant que le job tourne. Par défaut, sur Slurm, le fichier de sortie (slurm-<jobid>.out ou celui défini par --output) est en bufferisé par défaut, c’est-à-dire qu’il n’écrit peut-être pas ligne par ligne immédiatement. Pour forcer des écritures régulières, vous pouvez faire flush dans votre code ou lancer votre programme avec stdbuf -oL (pour line-buffered output). Ainsi, tail -f sortie.txt sur ce fichier vous montrera en temps réel les dernières lignes écrites. C’est pratique pour voir l’avancement (ex: votre programme peut imprimer "step 50/100 completed").
Vous pouvez aussi monitorer la consommation de ressources de vos jobs. La commande sstat ou sacct (après coup) donne l’utilisation mémoire, etc. Si vous êtes curieux pendant le run, vous avez accès au nœud (via ssh sur le nœud de calcul, ce qui est parfois autorisé en lecture seule), vous pouvez faire un htop et repérer votre processus. Mais généralement ce n’est pas nécessaire.
Utilisee l’interface web Open OnDemand, elle peut fournir un monitoring graphique de vos jobs (CPU, mémoire…).
En résumé : insérer des messages de progression dans vos jobs est un moyen facile de savoir ce qu’ils font. Sinon, patientez jusqu’à la fin et lisez le rapport final.
R : Oui, c’est possible en utilisant les jobs interactifs. Deux méthodes courantes :
salloc + ssh : vous demandez une allocation de ressources avec salloc (par ex: salloc -n 1 -c 4 --mem=4G --time=1:00:00). Quand l’allocation est accordée, votre prompt revient (toujours sur le login) mais avec des variables Slurm définies. Vous pouvez alors faire srun --pty bash pour spawn un shell sur le nœud alloué. Vous voilà sur un nœud de calcul, avec 4 cœurs réservés pendant 1 heure interactif. Là, lancez ce que vous voulez (Python, R, etc.) en mode interactif. N’oubliez pas de quitter (exit) lorsque vous avez fini, ce qui libère le nœud.
srun direct : plus simplement, srun --pty -n1 -c4 --mem=4G -t 1:00:00 bash combine en une commande la demande et l’ouverture du shell sur le nœud.
Enfin, rappelez-vous que sur le nœud de login, vous pouvez faire des petites choses interactives (comme tester une commande module ou éditer un script). Mais pour des calculs prolongés ou gourmands, toujours passer par un job (batch ou interactif). Il n’est pas autorisé d’utiliser le nœud de login pour du calcul. Si vous lancez accidentellement un programme sur le login, tuez-le (Ctrl+C si lancé au foreground, ou kill <pid> si en arrière-plan) et soumettez-le via Slurm !!! De même, une compilation doit se faire avec précaution, en limitant le nombre de coeurs utilisés.
R : Vérifiez d’abord avec module list que le module est bien chargé. Ensuite, peut-être le logiciel n’est pas dans le PATH mais disponible via une fonction. Par ex, certains modules définissent des alias ou variables sans ajouter de binaire. Consultez module show <module> pour voir ce qu’il fait. S’il s’agit d’une librairie (pas d’exécutable), il est normal de ne pas "voir" quelque chose directement – c’est aux programmes de lier la lib. Si c’est un outil censé fournir une commande, essayez d’ouvrir une nouvelle session après le module load ou assurez-vous qu’il n’y a pas de conflit de version (un autre module fournissant la même commande?). En dernier lieu, il peut s’agir d’un bug du module en question – signalez-le à l’équipe du cluster.
les modules deprecated ne sont là que pour simuler d’éventuels comportements possibles avec Muse, mais leur usage est à prescrire dans la mesu du possible, car certains ne fonctionnent plus.
|
R : Oui, mais il faut utiliser le X11 forwarding ou des outils dédiés. Si c’est une appli légère (ex: éditeur de texte graphique, outil de visualisation 2D), vous pouvez lancer un job interactif avec X11 (voir section Connexion – X11). Activez ssh -X depuis un poste Linux/macOS ou MobaXterm sur Windows puis, une fois sur le cluster, faites srun --x11 xterm par exemple pour ouvrir un xterm depuis un nœud de calcul. Si l’appli est plus lourde (3D), envisagez des solutions comme VirtualGL, l’interface web Open OnDeman, ou les noeuds de visualisation. En résumé, c’est possible mais les performances graphiques à distance sont limitées par votre réseau.
R : Le cluster étant un environnement distant, ce n’est pas idéal pour les programmes graphiques lourds. Cependant, pour des applications X11 simples (par ex. un éditeur de texte graphique, ou un utilitaire de visualisation), c’est possible via le X11 forwarding ou via des solutions comme Open OnDemand disponible ici : https://io-ood.meso.umontpellier.fr et le lancement d’un bureau virtuel (Interactive Apps > Remote Desktop.
En SSH, vous pouvez activer le forwarding X11 avec l’option -X (ou -Y pour du trusted forward). Exemple : ssh -X username@io-login.meso.umontpellier.fr. Si votre poste local est sous Windows, MobaXterm et Xming peuvent servir de serveur X pour afficher les fenêtres. Sous macOS/Linux, le serveur X est souvent disponible (sur Mac il faut installer XQuartz).
Notez que la latence réseau peut rendre l’usage graphique saccadé. Pour de la 3D ou du streaming vidéo, ce ne sera pas très performant.
Si vous avez besoin d’un environnement de bureau complet distant, passez par Open OnDemand (portail web avec accès bureau/Terminal) les nœuds de visualisation dédiés pour les tâches graphiques (avec GPU par ex).
En somme, pour un usage ponctuel de GUI légère, X11 forwarding suffit. Pour un usage intensif, mieux vaut parfois rapatrier les données sur votre poste de travail et utiliser des outils locaux.
R : Plusieurs possibilités :
Votre programme n’est pas effectivement parallèle (ex: code Python pure GIL ne scale pas au-delà d’un CPU, il faudrait du multiprocessing ou du vrai multithreading en C).
Vous avez saturé une ressource autre (I/O disque, bande passante mémoire) qui fait que plus de CPU n’accélère pas plus.
Sur plusieurs nœuds (MPI), le temps de communication l’emporte sur le calcul au-delà d’une certaine taille de cluster – c’est le scaling limité de l’algorithme.
Vous n’avez pas correctement paramétré l’environnement : ex: vous avez demandé 16 cœurs mais OMP_NUM_THREADS est resté à 1, donc votre programme n’utilise qu’un thread. Analysez les métriques : utilisez htop en session interactive pour voir si tous les cœurs sont occupés, ou ajoutez du profiling (temps par étape). Ajustez le code ou les paramètres en conséquence. Parfois, augmenter la taille du problème permet de mieux utiliser plus de cœurs (scaling fort vs faible).
R : Plusieurs options :
essayer Conda (beaucoup de logiciels bioinfo, data science y sont).
essayer un conteneur Singularity si une image existe.
Il y a aussi GUIX
En dernier recours, contactez l’équipe du cluster pour demander l’installation du logiciel en question – s’il est d’intérêt général, ils pourront peut-être l’ajouter aux modules. En attendant, vous pouvez tenter une compilation locale dans votre home (./configure --prefix=$HOME/local && make && make install), mais soyez conscient des limites (pas d’optimisation cluster, possible galères de dépendances). D’où l’intérêt des gestionnaires de paquets utilisateur comme Conda/Guix.
R : Le système de fichiers vous empêche l’accès. Plusieurs situations :
Vous essayez d’éditer ou lire un fichier dans un dossier qui ne vous appartient pas sans les droits nécessaires. Par exemple, cd /home/quelquun puis ls donnera "Permission denied" car vous n’avez pas accès au home de cet utilisateur. La solution : naviguer uniquement dans vos espaces (home, scratch perso, répertoires de projet où vous avez les droits). Si c’est un dossier de projet commun et que vous n’avez pas les droits, demandez à ce qu’on vous ajoute au groupe ou que les permissions soient ajustées.
Vous avez un fichier script que vous voulez exécuter directement (./monscript.sh) mais il dit "Permission denied". Vérifiez ls -l monscript.sh. S’il n’a pas le flag exécution (-rw-r—r-- par ex.), vous devez le rendre exécutable : chmod u+x monscript.sh. Alternativement, exécutez-le via l’interpréteur bash monscript.sh fonctionne même sans le x (car là c’est bash qui ouvre le fichier).
Vous essayez de compiler ou créer un fichier dans un dossier système (ex: /usr/bin). Assurez-vous de travailler dans un dossier en écriture pour vous (typiquement, votre home, scratch, ou /tmp dans un job). Si par exemple vous étiez dans /etc (que vous ne pouvez pas modifier), évidemment aucune écriture n’est permise.
"Permission denied" lors d’un scp/sftp en écriture : Vérifiez que vous copiez vers un chemin qui vous appartient. Si vous faites scp monfichier username@io-login.meso.umontpellier.fr:/home/autreuser/, vous n’avez pas le droit. Utilisez votre home.
Dernier cas : Permission denied sur une clé SSH (si vous utilisez des clés, et que le .ssh ou la clé privée a des droits trop ouverts, SSH refusera de l’utiliser). Par exemple, id_rsa doit être uniquement lisible par vous (chmod 600). Sinon SSH dira "Permissions are too open" et n’utilisera pas la clé, causant une demande de mot de passe ou un refus.
R : Cela signifie que vous avez atteint une limite de stockage :
Soit le disque lui-même est plein (peu probable sur un grand cluster, sauf cas particulier sur /tmp local ou un espace saturé). Vous ne pouvez alors rien y faire directement à part attendre que de l’espace se libère ou prévenir les admins si c’est anormal.
Soit votre quota personnel est atteint. Par exemple, si votre home a un quota de 200 Go et que vous les avez remplis, toute nouvelle écriture échouera. La solution est de faire du ménage : supprimez ou déplacez des fichiers du home vers scratch (si ce sont des fichiers volumineux temporaires, scratch est plus adapté).
Sur les espaces scratch, il y a aussi un quota. Parfois un message "quota exceeded" apparaît dans les logs du job. Là aussi, supprimez des fichiers sur scratch (utilisation du scratch : df -h /scratch/users/$USER).
Si c’est le nombre de fichiers (inode) qui est limité (très rarement atteint), ça peut être dû à des millions de petits fichiers. La solution est de nettoyer ou regrouper (archiver) ces petits fichiers.
Une fois de l’espace libéré, la commande qui avait échoué peut être retentée. Si c’était dans un job, corrigez et relancez le job.
R : Préférez rsync qui est optimisé pour les transferts multiples et peut reprendre les échecs. Exemple : rsync -avP dossier user@io-login.meso.umontpellier.fr:/chemin/cible. Sinon, compressez les petits fichiers en un gros (tar.gz) puis transférez ce seul fichier, avant de l’extraire sur le cluster (tar xzf). Cela réduit le nombre d’allers-retours. Si vous êtes sur Windows, WinSCP fait aussi du transfert partiel, et FileZilla propose une interface de batch. Enfin, assurez-vous que votre connexion est stable (en filaire de préférence). Le débit dépend aussi du réseau de votre lieu de connexion – sur de très gros volumes (>100 Go).
R : Il se peut qu’une modification ait cassé l’exécution des scripts d’initialisation. Par exemple, si vous avez mis une commande qui génère une sortie ou une erreur avant le chargement des modules, ça peut perturber. Ou si vous avez accidentellement ajouté un exit dans le fichier.
Éditez votre .bashrc et regardez ce qui cloche. Comparer avec l’original (souvent il y a des lignes initiales comme [ -z "$PS1" ] && return pour ne pas exécuter le reste pour les shells non interactifs). Si vous avez supprimé ce type de garde, le .bashrc peut interférer dans les shells non interactifs (comme ceux lancés par Slurm).
Pour conda, la ligne source ~/miniconda3/etc/profile.d/conda.sh doit être exécutée après que l’environnement de base (modules, etc.) soit prêt, et seulement pour les shells interactifs (vous pouvez la mettre dans .bashrc, c’est bien). Si conda ne fonctionne plus, essayez de réinitialiser en lançant conda init de nouveau.
En cas de gros pépin (shell qui ferme direct), vous pouvez toujours vous connecter en spécifiant un autre shell (ex: ssh username@io-login.meso.umontpellier.fr /bin/bash --noprofile --norc pour bypass vos fichiers rc et pouvoir éditer).
Règle générale : ne supprimez pas les parties générées par le système dans vos dotfiles (fichiers commençant par un ".", ajoutez plutôt les vôtres à la fin. Et testez après modifications.
R : Il arrive souvent qu’un utilisateur fasse partie de plusieurs groupes. Dans ce cas, il dispose d’un groupe primaire et de groupes secondaires. Il est possible de modifier dynamiquement son groupe primaire en utilisant la commande newgrp avec newgrp <nom du nouveau groupe primaire à utiliser>. Pour afficher son utilisateur et tous ses groupes, nous utiliserons la commande id :
# on liste tout
$ id
# on liste juste son groupe primaire uniquement
$ id -gn
# on liste juste ses groupes
$ id -Gn
$ newgrp mon-nouveau-groupe-primaire
$ id -gnA noter que le changement n’est pas persistent. Merci de le rajouter à votre ~/.bashrc si vous voulez que ça soit le cas pour chaque nouvelle session.newgrp <nom nouveau groupe primaire à utiliser>.
Vous devriez désormais avoir accès à votre dossier partagé. Si ce n’est toujours pas le cas, merci de faire un ticket sur https://isdm-tickets.meso.umontpellier.fr