Sujets Exploitation+Stockage:
----------------------------------
Prod
----
- SL5 : le rack idataplex 252-293 est en prod. Les 2 autres ne le sont pas.
- WLCG : faire le mail pour l'arrêt Dcache : je n'ai pas eu le temps.
- IGL : ils veulent lancer avec l'accord de DB une prod de 500 jobs la semaine prochaine sur newLINUX.
il faut surement augmenter leur ressource sps j'ai vu avec PC ils ne sont pas dangereux pour GPFS.
- D0 : n'a pas assez de jobs en RUN sur SL4??? je n'ai pas su quoi faire...Le pbm sps a été traité directement entre LT et PL.
- ATLAS : surveiller leur prod elle a du mal à passer sur SL4 (1600) dés que LHCB et CMS viennent or ils en ont besoin.
J'ai réajusté les ressources. Leur share sont en place comme le dmde catherine : JD a corrigé le bug des max running pour le common.
- WNS : 230 workers ont été sortis aujourd"hui par erreur d'ou la chute des jobs RUN en fin de matine.Pbm réglé avec micael, il s'est trompé en voulant réinstaller le iDataplex.
- Grille : la migration des CEs vers SL5 s'est bien passé . Aucune perte de jobs.
RC report : rempli.
Arrêt Dcache : planifié, les CEs ne seront pas arrêtes mais les VOs alertées du risque pour leur jobs avant/aprés l'intervention
il faut surement relancer le support là dessus!
- SL4 : trés chargée. Bonne chance pour répartir les objectifs....
- HPSS : RAS
- NAGIOS : il ne réagit pas aux requêtes de DIVA pendues depuis ++ de 24h.
J'ai mis à jour les sondes pour Xrootd et SRB.
Q : pq il ne check pas l'etat d'une machine test/UP avt de lancer la sonde Marc? merci.
- COM : Ghita propose une nouvelle structure pour ces annonces. L'idée est sympa : à voir.
- CDF : a travers un ticket /mails ils se sont plaint d'un manque de collaboration de notre part à Dominique.
- LHCB : j'ai confié le probléme relevé par PhO à David
- SUPPORT : ils ont mis en place une recette pour condor : à valider avec eux suzanne stp.
- BQS : migration planifiée par BC et JD la semaine prochaine.
Robotique
----------
- La salle et les SLs/Bandes sont trés sales : il faut faire quelques chose!
- Bcp de montage de CLEAN et d'incidents cette semaine.
- Bcp d'incidents sur les lecteurs : consulter la base on l'a mise à jour avec FB.
Le lecteur diva 0,2,1,14 semble malade.
- Bandes : 5 incidents pris en cours la base est à jour.
ITC099 : avec les données de CMS a été récupérées.
- Creation : IS: le labellage a posé bcp de problémes. il est presque fini.
On a fait des échanges de bandes mais cela n'a pas suffit et on a isolé le lecteur 0,2,1,14 de DIVA.
Il y a des recherches à fair même JD est perplexe...
A traiter : IT8704 ITB009 JT0310 Ces bandes sont dans ACSLS et pas dans HPSS !
JT : 200 migrations OK les import sont en cours.
Sujets Support:
-------------------
_ATLAS_
*** remplissage de la zone de releases SL4
- l'avancement du remplissage de la nouvelle zone de software sl4 (/afs/in2p3.fr/sftgroup/atlas) a ete accidentellement retarde (des release ont ete
effacees par erreur);
- le remplissage de cette zone continue mais lentement car il faut mnettoyer les zones de releases avant de re-installer et une seule release peut etre
instalee a la fois.
*** remplissage de la zone de releases SL5
- la zone de releases SL5 (/afs/in2p3.fr/sftgroup/atlassl5) a ete mise en place par Fabien
- cc-atlas est en train de la remplir avec les soft ATLAS appropries (SL4+librairies de comptabilite SL5)
- pas mal de problemes avec le remplissage de cette zone;
- les installations marchent via le cclcgceli09 (brand new SL5 CE) mais echouent sur les CEs qui etaient originalement SL4 et ont ete tournes SL5
(cclcgceli02).
- la aussi, lenterur car une seule release peut-etre installee a la fois.
*** UAT/ xrootd
- JY a observe des problemes de saturation reseau
- ils ont ete associes aux jobs qui utilisaient les releases de la nouvelle zone SL4 et dans lesquelles les parametres reseaux de root n'avaient pas ete
modifies (root <5.20 est bugge - probleme connu);
- apres correction des rootsysrc (releases 14 utilisant root 5.18 corrigees, releases 15 utilisant root 5.22 NON modifiees), le meme probleme a ete
observe. Nous ne savons pas quelle est la cause de cette saturation. Attendons le retour de JY mercredi 4 nov. pour diadnostic.
*** a noter
- ATLAS-France (E. Lancon) a demande une modification des shares et notament le nombre de jobs running sur les shares d'analyse a ete limite (~ 2 fois
le nb de slots du share), ceci afin de ne pas retarder l'entree des jobs sur le T1 lorsqu'il a ete sans jobs pdt quelque temps. L'effet de ces changements
doivent etre observes in-situ.
_CMS_
SAM test and site readiness:
**********************
The CE SD declared in GOC DB was reported as unscheduled.
So, SAM test did not take into account the unscheduled downtime.
During the 2 days and a half the SAM test failed, and the site readiness
was impacted by this failure.
The issue was reported to Pierre and the action was considered to avoid that next time.
Transfers
********
- Some missing files: a check to see if the files were lost or the files were never be transfered
to us...still open issue
_ALICE_
la prod est repartie (doucement) depuis lundi
probleme de memoire dans les jobs de production : superieure a la limite de 2GB
l'exploitation doit regarder ce pb , qui a l'air commun egalement a atlas et cms
_LHCb_
1) Une partie des jobs de lhcb était tuée par memory exceeded, car ils tombaient dans la classe A, alors qu'ils
demandaient 100000 s de CPU time. Le problème venait d'un bug dans le 'match-making' de Dirac et il a été corrigé.
2) Tous les jobs pilots terminaient 'aborted' sur cclcgceli08, à cause d'un problème de mis-configuration de
cclcgceli08, fixé par Pierre.
3) La solution d'augmenter le nombre de movers par pool dans dCache n'a pas résolu completement le problème des
connexions qui restent bloquées -> A voir avec les dcachemasters.
Problèmes récurrents:
-------------------------
AT Grille généralement:
----------------------------
- CE, BDII, VOMS...
- SE, FTS, LFC, SRM, dCache