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.
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 ?
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?
assigned to nalin
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.