Bug 428337
| Summary: | lckpwdf creates useless lock file /etc/.pwd.lock | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wayne Pollock <pollock> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-04-10 12:12:19 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: | |||
The file is used for locking, not the existence of the file means it is locked. Instead, fcntl with F_SETLKW is used on it. The existence of this file does NOT mean the passwd files are locked, please look again at the code I showed. This is the essence of the bug report. It *should* mean that, but it doesn't! If the file isn't used for locking, it should not be created. And whether or not it is used for locking, ulckpwdf should remove it if lckpwdf creates it! I don't agree that this is not a bug! Please take another look. Either lckpwdf shouldn't create the lock file at all (as it appears unused), or *if* it get created with lckpwdf *then* it must be removed with ulckpwdf! Currently lckpwdf creates this lock file, and ignores it completely thereafter. I have no idea why do you think existence of a file should mean the lock is held, you can't use a file for that reliably. The existence of the file WITH ADVISORY LOCK on it held means the passwd files are locked. This works as designed. |
Description of problem: As the following shows locking works correctly. And lckpwdf correctly (?) creates a lock file "/etc/.pwd.lock". However that file doesn't appear to be used for locking, just created as a side-effect! And ulckpwdf doesn't remove the file! Version-Release number of selected component (if applicable): Probably all, but: glibc-common-2.6-4 glibc-devel-2.6-4 glibc-headers-2.6-4 glibc-2.6-4 shadow-utils-4.0.18.1-15.fc7 "uname -a" shows (in part): Linux localhost 2.6.23.1-21.fc7 How reproducible: Always. Steps to Reproduce: cat >lckpwdf-test.c <<\EOF #include <stdio.h> #include <shadow.h> int main (void) { int status = lckpwdf(); printf("(status=%d) hit enter to quit: ", status); getchar(); status = ulckpwdf(); return status; } EOF # make lckpwdf-test # ls -l /etc/.pwd.lock # IT ISN'T THERE TO START WITH: ls: cannot access /etc/.pwd.lock: No such file or directory # ./lckpwdf-test (i=0) hit enter to quit: # echo $? 0 # ls -l /etc/.pwd.lock # THE FILE SHOULD HAVE BEEN REMOVED, BUT: -rw------- 1 root root 0 2007-12-31 10:06 /etc/.pwd.lock # ./lckpwdf-test & SHOULDN'T WORK IF THE LOCK FILE IS THERE, BUT: [1] 12414 (i=0) hit enter to quit: [1]+ Stopped ./lckpwdf-test # ls -l /etc/.pwd.lock -rw------- 1 root root 0 2007-12-31 10:48 /etc/.pwd.lock # ./lckpwdf-test # THIS SHOWS LOCKING WORKS REGARDLESS OF THE LOCK FILE: (i=-1) hit enter to quit: # echo $? # CORRECTLY FAILS WHEN ANOTHER PROCESS HAS THE LOCK: 255 # fg ./lckpwdf-test # echo $? 0 # ls -l /etc/.pwd.lock # SHOULD HAVB BEEN REMOVED, BUT: -rw------- 1 root root 0 2007-12-31 10:48 /etc/.pwd.lock