Hi Jordan, Could there be a typo? In your emails, you’ve written:
AccountingStorageEnforce=assocciations but it should be AccountingStorageEnforce=associations Cheers, Ben From: Jordan Willis [mailto:[email protected]] Sent: 15 June 2015 01:38 To: slurm-dev Subject: [slurm-dev] Re: UserAccounts on SLURMDBD Also, The slurmdb log file reads like this #For non existant user slurmdbd: debug4: We can't get a db_index for this combo, time_submit=1434328391 and id_job=11834 and id_assoc=0. We must not have heard about the start yet, no big deal, we will get one right after this. slurmdbd: debug2: DBD_STEP_START: ID:11834.0 NAME:echo SUBMIT:1434328391 slurmdbd: debug2: as_mysql_slurmdb_job_start() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_JOB_START: START CALL ID:11834 NAME:echo INX:0 slurmdbd: debug2: as_mysql_slurmdb_job_start() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_JOB_COMPLETE: ID:11834 slurmdbd: debug2: as_mysql_slurmdb_job_complete() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_STEP_COMPLETE: ID:11834.0 SUBMIT:1434328391 slurmdbd: debug4: got 0 commits slurmdbd: debug4: got 0 commits #For Me slurmdbd: debug2: DBD_STEP_START: ID:11835.0 NAME:echo SUBMIT:1434328409 slurmdbd: debug4: We can't get a db_index for this combo, time_submit=1434328409 and id_job=11835 and id_assoc=4. We must not have heard about the start yet, no big deal, we will get one right after this. slurmdbd: debug2: as_mysql_slurmdb_job_start() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_JOB_COMPLETE: ID:11835 slurmdbd: debug2: as_mysql_slurmdb_job_complete() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_STEP_COMPLETE: ID:11835.0 SUBMIT:1434328409 slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_JOB_START: START CALL ID:11835 NAME:echo INX:0 slurmdbd: debug2: as_mysql_slurmdb_job_start() called slurmdbd: debug4: got 0 commits slurmdbd: debug2: DBD_CLUSTER_CPUS: called for schief_cluster(1520) slurmdbd: debug4: got 0 commits It’s looking like it defaults to id_assoc=0. How do I change that default behavior? On Jun 14, 2015, at 5:32 PM, Jordan Willis <[email protected]<mailto:[email protected]>> wrote: Thank you Remi, I’m almost there. If I have added a user to the cluster account, then it will show up with sacct as expected. However, if I sudo into another user, and try and submit a job, it will let me, and just leave the accounting blank. #Me $srun echo hello world $sacct --format JobId,JobName,Partition,Account,User JobID JobName Partition Account User ------------ ---------- ---------- ---------- --------- 11831 echo all my_user_acct+ myusername $sudo -u someotheruser bash #Someone else $srun echo hello world $sacct --format JobId,JobName,Partition,Account,User ->sacct --format JobId,JobName,Partition,Account,User JobID JobName Partition Account User ------------ ---------- ---------- ---------- --------- 11832 echo all someotheruser As you can see, if the user has not been added to the account, it will leave this field blank. Incidentally, if I specify the actual account with —account, it will show up, and that person will still be able to run. What am I missing with AccountingStorageEnforce=assocciations? Do I have to add something to the cluster to associate it with the users? I think it may have something to do with this. ->sacctmgr -s show Association Cluster Account User Partition Share GrpJobs GrpNodes GrpCPUs GrpMem GrpSubmit GrpWall GrpCPUMins MaxJobs MaxNodes MaxCPUs MaxSubmit MaxWall MaxCPUMins QOS Def QOS GrpCPURunMins ---------- ---------- ---------- ---------- --------- ------- -------- -------- ------- --------- ----------- ----------- ------- -------- -------- --------- ----------- ----------- -------------------- --------- ------------- my_cl+ root 1 normal my_cl+ root root 1 normal my_cl+ my_user_acct+ 1 normal my_cl+ my_user_acct+ myusername 1 normal It seems that there is a blank username in the associations that may be allowing anyone to run? Thanks so much for the help again, Jordan On Jun 14, 2015, at 2:16 AM, Rémi Palancher <[email protected]<mailto:[email protected]>> wrote: Le 14/06/2015 08:53, Jordan Willis a écrit : Hello, Thanks for answering my questions over the past few weeks. I have enabled slurmdbd and it seems to connect fine to my controller. I then added a cluster, sacctmgr add cluster my_new_cluster 1. Should my_new_cluster match the ClusterName in slurm.conf? Yes. If this not currently the case, fixing this should also fix 2/ and 3/. 4. When adding users, is there anyway to automatically add the users in /etc/passwd? How do the accounts of a person submitting get linked with the accounts added by sacctmgr add user No, slurm has no control over /etc/passwd file since POSIX users could also be hosted in an LDAP directory or so. You have to write your own scripts to add users in both SlurmDBD and /etc/passwd, not a big deal though :) You have to mind there are 3 levels of user/account involved with SlurmDBD: - POSIX users (in /etc/passwd or LDAP) - SlurmDBD users - SlurmDBD accounts POSIX and SlurmDBD users must share the same name/login, so the mapping is direct. Then users can control their jobs account using --account submission parameter. If not given, the default SlurmDBD account associated to their SlurmDBD user is used. There are also many resources available online on this matter: http://slurm.schedmd.com/slurm_ug_2012/SUG_Oct2012_DBD.pdf https://www.youtube.com/watch?v=8UfzXnzSmL4&feature=relmfu http://slurm.schedmd.com/accounting.html rémi
