slurm
at:qstat -n $JOB_ID # oder allgemein qstat -n -1 |less <JOB-ID>
checkjob $JOB_ID
grep nach der Jobnummer in den Logfiles von maui:
grep -r $JOB_ID /var/spool/torque/maui/log/
qmgr -c "print server"
pbsnodes # wichtiger Spezialfall, nur _ein_ 'Typ' pbsnodes :Intel.X5650 pbsnodes :AMD.FX6274
pbstop
qalter -l walltime=48:00:00 $JOB_ID
node=node001 qmgr -c "create node $NODE" qmgr -c "set node $NODE properties+=infiniband" qmgr -c "set node $NODE np=24"
node=node001 qmgr -c "delete node $NODE"
Normale Wartungsarbeiten ohne 'Notfall' - Offlinesetzen, Jobs abwarten, Wartungsabeiten, Onlinesetzen:
node=node001 pbsnodes -N "Begruendung" -o $NODE # warten bis jobs enden (TODO benachrichttigung wenn fertig) # ... Wartungsarebiten... pbsnodes -N "" -c $NODE
set queue $QUEUE acl_group_enable = True set queue $QUEUE acl_groups = $GROUP set queue $QUEUE acl_group_sloppy = TrueNB: ohne
acl_group_sloppy
werden nur Primärgruppen des Benutzers geprüft.
set queue $QUEUE acl_user_enable = True set queue $QUEUE acl_users = $user1 set queue $QUEUE acl_users += $user2
set queue $QUEUE acl_group_enable = True set queue $QUEUE acl_user_enable = True set queue $QUEUE acl_group_sloppy = True set queue $QUEUE acl_groups = $group set queue $QUEUE acl_users = $user1 set queue $QUEUE acl_users += $user2 set queue $QUEUE acl_logic_or = TrueNB: ohne
acl_logic_or
müssen Benutzer- und Gruppen-ACL erfüllt sein.
# setres -s 00:00_02/18 -e 00:00_03/11 -g $GROUP 'node02[3-6]' reservation created reservation '$GROUP.0' created on 4 nodes (96 tasks) node023:1 node024:1 node025:1 node026:1Format für -s,-e:
[HH[:MM[:SS]]][_MO[/DD[/YY]]] ie 14:30_06/20)
Löschen der Reservierung: releaseres $GROUP.0
Aus ungeklärter Ursache geht immer nahh dem Neustart eines Knotens der erste Job darauf schief, weil es 'mom' immer beim ersten Mal nicht gelingt die Job-Directory anzulegen. Da das anscheinend nur genau ein Mal passiert, muss man einen 'Opfer-Job' starten, der dann den Fehler auslöst und beseitigt. Vorher dürfen keine wartenden Jobs auf den frisch rebooteten Knoten gescheduled werden.
Vorgehensweise daher (Commands auf dem master):
# dieser Admin-User und der gegebene 'node'NNN: ADMIN=${SUDO_USER:-$USER}; NODE=001; # bis zum Ende aller laufenden Jobs offline setzen pbsnodes -o -N "reboot pending" node$NODE # warten, bis der Knoten 'idle' und 'free' ist. # cluster-intern einloggen in node$NODE z.B. sudo -u $ADMIN rsh -l $ADMIN node$NODE sudo /bin/bash -li # mit _dieser_ shell anstehende Arbeiten ausführen # (e.g. sync, grub-install, ...), dann reboot
Solange der Knoden noch offline gesetzt ist, reserviert man den Knoten für 'uns' (hier Admin-Group 'adm'):
# unbegrenzt reservieren (wie im entsprechenden Unterpunkt) setres -n boot$NODE -s +00:00 -d 0 -g adm node$NODE # Kontrolle: showres | grep '^boot' # Warteschlange für den Knoten wieder freigeben # mit entsprechendem Kommentar (Besipiel) pbsnodes -c -N "done" node$NODE
Dann erzeugt man mit dem hier attachten Script zwei dummy-Jobs, die wegen der Reservierung alleine laufen, und wegen der erfolgten Freigabe auch sofort ausgeführt werden sollen.
# zwei jobs erzeugen ./dummyjob.sh $NODE; ./dummyjob.sh $NODE # Kontrolle: qstat -u $ADMIN
In diesem Moment sollten die zwei Jobs auf dem Knoten ausgeführt werden, wobei der erste den Fehler beseitigt und der Zweite korrekt abläuft.
Nach der Kontrolle des (meist nur einen) Outputs die Reservierung aufheben.
Wenn die Jobs nicht zeitnah starten, kann man sie, mit ihrer Jobnummer aus dem obigen Statusperqrun
explizit anwerfen.
# eventuell Jobs explizit zuweisen qrun -H $NODE nnnn1 nnnn2 # Kontrolle des Outputs im Admin-Home auf dem Knoten sudo -H -u $ADMIN rsh -l $ADMIN node$NODE cat dummyjob.node$NODE.\* # Freigabe des Knoten fuer alle User (i.e. Entfernen der Reservierung) releaseres boot$NODE.0
I | Attachment | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|
![]() |
dummyjob.sh | manage | 1 K | 16 Mar 2013 - 01:46 | UnknownUser | shellscript zum Erzeugen eines jobs fuer einen admin auf genau einem node |