Réunion coordination WLCG Lyon, le 13 mars 2008 sreynaud@in2p3.fr mardi 31 juillet 2018 Tests glexec/BQS Réunion coordination WLCG Lyon, le 13 mars 2008 sreynaud@in2p3.fr

Contraintes de déploiement de glexec Conclusion et discussion Plan Rappel du contexte Tests avec BQS Description Résultats Contraintes de déploiement de glexec Conclusion et discussion

solution choisie au niveau du projet Rappel du contexte problème lorsque 2 jobs pilotes soumis avec un même proxy tournent sur une même machine, les "user jobs" de 2 utilisateurs différents ont les mêmes droits d'accès sur leurs fichiers (y compris leur proxy!). solution choisie au niveau du projet les jobs pilotes s'engagent à appeler glexec pour chaque "user job" les sites doivent déployer glexec => nécessité de vérifier le comportement de BQS en cas de changement d'utilisateur Unix

Rappel du contexte

Description des tests (1/2) Référence calcul pendant T minutes Test 1 job change d'UID, fork et attend la fin du fils fils calcule T minutes Test 2 job change d'UID, fork et attend T minutes fils fork et se termine petit-fils calcule T minutes Test 3: idem test 2 + … petit-fils change de process group ID avant de calculer Test 4: idem test 2 + … petit-fils crée une nouvelle session avant de calculer Test 5 job fork et attend T minutes fils fork et se termine petit-fils change d'UID et calcule T minutes

Description des tests (2/2) Sleep 30" au début de chaque test Durée du calcul 1 minute 2 minutes jusqu'à ce que BQS tue le job (environ 5 min.) jusqu'à ce que le user tue le job (qdel) 2 jobs simultanés d'un même utilisateur pendant 2 minutes job de référence + chacun des tests test 2 + test 3 test 4 + test 5

Comportement attendu pour tous les tests Résultats des tests Comportement attendu pour tous les tests Détection du dépassement de CPU et kill par BQS Kill par l'utilisateur via qdel Comptabilité sous-estimée d'une 15aine de secondes dès que le calcul est effectué par un processus fils de 1 Un cas d'erreur détecté pour job de référence + test 5: comptabilité sous-estimée de plus de 30" 0:19:48 au lieu de 0:43:38 (en temps normalisé) non reproductible

Contraintes de déploiement Version déployée glexec 0.5.23-3 http://eticssoft.web.cern.ch/eticssoft/repository/org.glite/org.glite.security.glexec/0.5.23/slc4_ia32_gcc346/glite-security-glexec-0.5.23-3.slc4.i386.rpm gLite-WN 3.1 /afs/in2p3.fr/system/@sys/usr/local/grid/glite/3.1.4-1/WN/ /afs/in2p3.fr/system/@sys/usr/local/grid/glite/3.1.4-1/WN-glexec/ http://glitesoft.cern.ch/EGEE/gLite/R3.1/glite-WN/sl4/i386

Contraintes de déploiement binaires glexec et glexec_fork setuid bit pas dans n'importe quel volume (sinon fonction seteuid() échoue) compte local glexec:glexec (pour des raisons de sécurité) /etc/ld.so.conf (car LD_LIBRARY_PATH perdu en route…) des chemins en dur /opt/glite/etc/glexec.conf (pour des raisons de sécurité) /usr/lib/libgridsite* /etc/grid-security: mêmes besoins que pour un CE grid-mapfile, gridmapdir, vomsdir… attention aux permissions sur les fichiers de configuration ! lcas-glexec.db, lcmaps-glexec.db, ban_users.db, grid-mapfile…

Conclusion et discussion support de glexec par BQS perte d'une partie de la consommation CPU avec les conditions de test suivantes: 2 jobs pilotes d'une même VO sur même machine 1 job pilote appelle glexec dans le processus principal 1 job pilote appelle glexec dans un processus fils de 1 2 jobs utilisateur avec le même proxy + une condition non identifiée… (bug non reproductible) déploiement de glexec sur les workers déployer les packages sur AFS ne suffit pas OK ?