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]> 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 >> <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 >
