Bug 3575 - After user UID change: Invalid account or account/partition combination specified
Summary: After user UID change: Invalid account or account/partition combination speci...
Status: RESOLVED INFOGIVEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: Accounting (show other bugs)
Version: 16.05.8
Hardware: Linux Linux
: --- 4 - Minor Issue
Assignee: Director of Support
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2017-03-13 09:19 MDT by Ole.H.Nielsen@fysik.dtu.dk
Modified: 2017-03-17 15:53 MDT (History)
2 users (show)

See Also:
Site: DTU Physics
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ole.H.Nielsen@fysik.dtu.dk 2017-03-13 09:19:47 MDT 
We had to change the UID in /etc/passwd of a Slurm user "stly", and the /etc/passwd was propagated to all nodes in the cluster.  However, after the UID change, the user could no longer submit batch jobs, but got an error message:

sbatch: error: Batch job submission failed: Invalid account or account/partition combination specified 

The only way I could solve this was:

sacctmgr delete user stly

and then recreate his account:

sacctmgr create user name=stly defaultaccount=ecsvip

Questions: 

1. Should Slurm be agnostic about user UIDs, or is the UID used internally through some caching?

2. Do you have a recommended procedure for modifying user UIDs (and group GIDs)?
Comment 1 Tim Shaw 2017-03-13 10:42:50 MDT 
Ole,

When changing UIDs, you will also need to restart the slurmctld for the changes to take effect.  Normally, when adding a user to the system the UID is filled in automatically and immediately.  If the user isn't known on the system yet, there is a thread that runs every hour that fills in those UIDs when they become known, but it doesn't recognize UID changes of preexisting users.  But you can simply restart the slurmctld for those changes to be recognized.

Do you think it would be helpful to add this to our FAQ?

Tim
Comment 2 Ole.H.Nielsen@fysik.dtu.dk 2017-03-13 12:14:02 MDT 
(In reply to Tim Shaw from comment #1)

> When changing UIDs, you will also need to restart the slurmctld for the
> changes to take effect.  Normally, when adding a user to the system the UID
> is filled in automatically and immediately.  If the user isn't known on the
> system yet, there is a thread that runs every hour that fills in those UIDs
> when they become known, but it doesn't recognize UID changes of preexisting
> users.  But you can simply restart the slurmctld for those changes to be
> recognized.

Thanks for explaining the task recognizing user UIDs.  It isn't obvious from any of the man-pages that UIDs matter (except that they must be uniform across the clusters).

> Do you think it would be helpful to add this to our FAQ?

Absolutely! It's one of those rather rare tasks which shouldn't clutter the man-pages, so the FAQ would seem the logical place to explain what to do after modifying a user's UID.
Comment 5 Tim Shaw 2017-03-17 15:53:53 MDT 
Ole,

I've added an entry for this and here's the commit id:

40d43ce2372f27

It will be posted to our online FAQ soon.

I'm resolving this ticket.  Let me know if you have any further questions.

Regards.

Tim