Bug 126709 (IT_45122_41789)
| Summary: | [PATCH]passwd.lock and group.lock file is never removed after using the command useradd | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Franklin Abud <fabud> | ||||
| Component: | shadow-utils | Assignee: | Eido Inoue <havill> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.0 | CC: | abartlet, jbriggs, mgarski, riel, tao | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | 4.0.3-29 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-12-13 20:57:10 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 123574, 133398 | ||||||
| Attachments: |
|
||||||
shadow-utils version is shadow-utils-4.0.3-20 Indeed the passwd.lock file is not being removed, but for some reason it's existance is not interfering with normal useradd or passwd usage. Subsequent runs of useradd do update the passwd.lock, and runs of passwd don't seem to. Oh, I see. It becomes a problem when another process reuses the PID, and suddenly you can't use useradd. My Bad. Created attachment 102289 [details]
Patch to shadow-utils-4.0.3-20 so useradd unlocks files when closing them and unlocks them on failure.
I've verified this patch works on RHEL3AS-U2.
Just a little note: shadow.lock file is also never removed. *** Bug 21038 has been marked as a duplicate of this bug. *** OK, so the patch has been tried by at least 3 of our support people. I'll apply it to the rawhide RPM as part of the FC3 bug week effort. *** Bug 27004 has been marked as a duplicate of this bug. *** Yay! And it only took 4 years to get fixed. :-) An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-527.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-472.html |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Description of problem: after using the useradd command the lock files are never removed, The problem occurs if you get another process that runs and has the same PID as the one stored in the lock files. When this happens, useradd refuses to add the user because it thinks that the running process has locked the file. The customer has a lot automated useradd/deletes process. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.useradd test 2. watch cat /etc/passwd.lock 3. useradd test1 Actual Results: after the useradd command is done doing it's thing the lock file should be removed Expected Results: the lock file remains Additional info: I'm still in the process of getting the version of shadow-utils they are using.