Messages in this thread | | | Date | Mon, 14 Sep 1998 10:41:19 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: showstopper race condition in sync() ??? [2.1.119|120] |
| |
Hi,
In article <Pine.GSO.4.02A.9809131325020.4060-100000@laureline>, Cyrille Chepelov <chepelov@rip.ens-cachan.fr> writes:
> everything works fine, until someone tries to change his password. The > first ten users could change their password, but now, whenever they do > this, the "passwd" process locks up, can not be killed (tried kill -1 and > -9), and subsequent calls to "sync" lock with the same symptoms.
> ...
> After a reboot, I tried to change a password under strace's control. > Passwd locked itself up while calling "sync()", after succesfully changing > the password.
This is a sign that an IO has got stuck in the kernel's block device buffer cache. Given that the problem is in the sync(), it is most likely to be that a write to the password file or lock file itself which is causing the problem.
> I can give the passwd file if someone is motivated to try to reproduce the > problem (but I'd be happier without doing so <grin /> )
It won't help: the problem is down in a device driver somewhere, and is most unlikely to be related in any way to the file contents. My first reaction would be to run "badblocks" on the disk ("e2fsck -c") to check for and to relocate bad blocks on the disk, and then to try again. If it is still reproducible, then let me know.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html
| |