Bug 5195 - passwd sometimes hangs
passwd sometimes hangs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: passwd (Show other bugs)
6.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-09-17 15:39 EDT by matthew.temple
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-22 11:36:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description matthew.temple 1999-09-17 15:39:13 EDT
Occasionally, the "passwd" command hangs, and hangs in a
severe enough way that the process trying to change the
password cannot be killed.   The result is that the
/etc/passwd database is write locked and cannot be altered
until the machine is rebooted.   Normal reboot fails,
because the drives cannot be unmounted, so a forced crash
needs to be implemented.   I discovered this when running an
expect script, but was able to duplicate it when logged in
as root at the console.
Comment 1 Cristian Gafton 1999-09-22 23:40:59 EDT
This does not look like a passwd problem. There is some other problem
going on your system that brings it down - passwd can not bring the
whole system down. And passwd definitely has safeguards against the
locks it places on the /etc/passwd files (and others in /etc) so that
it will not lock itself out.

Please try to diagnose what is really happeining on your system or
send in more information if you really belive that passwd is bringing
down your system. To me looks like a hard drive failurre or some other
type of hardware issue.

Does anything shows up in /var/log/messages ?
Comment 2 matthew.temple 1999-09-24 10:28:59 EDT
I've noticed something else here -- this phenomonon seems (hard to
tell because it is inconsistant) to happen when the password change
is done by root when root has "su'd" from another user, but not when
root has logged in at the console or has directly logged in via ssh.
We will experiment further to verify this, but I have anecdotal
evidence of this kind of event from three other users of ours on other
RH 6 computers.   I also recall this happening with 5.2 but never
filed a bug report.

------- Additional Comments From   10/05/99 13:12 -------
From matthew.temple as above:
	We replaced the hard drive in question with a new hard drive and
performed a fresh install.   (Old system had been upgraded from 5.2 to
6.0.)   Even with the new drive, the problem is still present.
Further details -- This computer is using an ASUS PSB-D board and an
Adaptec 2940UW scsi controller.   We've ordered an IDE drive which we
will install as our boot disk to see if we have a SCSI driver problem.

	We've also found that a process can hang running edquota.
Further, we never had any issues when this computer was at 5.2, even
after we'd recompiled the kernel with the then "experimental" SMP
support.
					mht
	So far, in three years of Linux, this is the first bug that has me
stymied.

------- Additional Comments From   10/20/99 14:33 -------
        So, we installed the operating system on an IDE instead of the
SCSI drive it had been on.  But the phenomenon still persists.  The
only evidence that you get in the messages file looks like this:

Oct 21 14:06:09 limb PAM_pwdb[3298]: (su) session closed for user root
Oct 21 14:06:09 limb PAM_pwdb[3336]: user (lcai/13074) update failed;\
                pwdb: another process has locked resource

There was a passwd.lock file in /etc/ but, not surprisingly, deleting
this doesn't help.

Does it help to mention that this is on a dual processor Pentium ASUS
PSB-D motherboard?

As far as we can tell, the only anomaly on this machine is this
passwd command hang.  The current version of the OS was installed
fresh.

Originally, the problem occurred on a computer that was upgraded from
RH5.2 to RH6.0.   We'd never experienced this problem with RH5.2.
Could this possibly be related to the dual-processor kernel?

What other information can I provide that might help answer this?
Comment 3 Cristian Gafton 2000-05-22 11:36:59 EDT
assigned to nalin
Comment 4 Brent Fox 2002-06-05 00:01:40 EDT
I'm going to close this report due to it's age.  If you see this behavior with a
more current Red Hat Linux release, please reopen this report.

Note You need to log in before you can comment on or make changes to this bug.