lkml.org 
[lkml]   [1998]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:1.304 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site