Description of problem:
Two users can not change their password at the same time.
Version-Release number of selected component (if applicable):
passwd-0.64.1-7 on RedHat Advanced Server 2.1 (with all errata updates)
Steps to Reproduce:
1. Login as a user (other than root).
2. Type passwd. Then do not type anything.
3. Login again as any user.
4. Type passwd.
The second time you type passwd, nothing happens. As soon as the first user
finishes changing their password, the second user is able to change their
How can RedHat Advanced Server be advertised as an "Enterprise" product if you
can not do something as simple as having two users change their password at the
same time??? This also applies to users who have their password expired.
After they login they are forced to change their password, but if someone else
is changing their password at that time, all that user can do is just sit there
and wait their turn. This is a HUGE problem for us because we are about to go
live on a 1000+ user (400+ concurrent) order entry server. This password
change problem is unacceptable. If a solution can not be found, I will be
forced to look for an alternative OS. In my opinion this should be a top
priority for RedHat. We are planning on going live with this new server in the
next couple of weeks, so a quick response would be appreciated.
This does not apply to root. The root user can have as many passwd sessions
opened as needed. I have also verified that this is true on RedHat 7.2, 7.3,
Hello???? Anyone out there?????
Can I get an update on this? Can anyone else confirm there is a problem here?
Is there a fix in the works?
First of all, please have a look at:
Maybe introducing a similar timeout as like AIX is an option.
The problem seems to be with a file called /etc/.pwd.lock
This file is created when a user tries to change their password :
-rw------- 1 root amy 0 Aug 2 19:24 .pwd.lock
As you can see, only root can access the file despite the fact
they've gone to the trouble to set the group. As RH uses "private
groups" it is normal for the username to match the groupname. I
imagine this is used to determine which user is changing their
Unfortunately whilst this file exists, normal users cannot change
their own passwords. Instead the passwd program sits and waits for
the previous program to finish running. The other users password
prompt then carries on as normal.
I'm currently investigating what part the lock file plays in the
password change process to see whether or not this problem can be
just to add a bit of weight;
AFAIK, this has been a problem since RHL 6.2 (or earlier) and affects
Fedora also (but not Debian or Slackware)
we now have a customer, where this fix is on the critical path, RHEL4 ?
This is fixed through the latest RHEL 2.1 pam errata.
Does that mean that it is fixed in RHEL 3 and RHEL4 as well? Do those versions
require a patch to pam as well to make this work? What specific patch level is
required for the fix?
Yes, it is fixed in RHEL4 and in RHEL3 U4.