Greetings,

I'm running a Red Hat Linux 3.2.3-52 on a 2.4.21-32.0.1 ELsmp kernel.

We have a couple of Red Hat systems that, when you try to change your password, just hangs. So far the admins here have rebooted the box and it's resolved the problem. I had them hold off last time while I checked in to it but they needed to get someone in to the system so they rebooted.

Now the problem isn't going away with a reboot.

The pam files are dated Jun 4 2004 with a couple of others with an older 2003 date.

The /etc/pam.d/passwd file:

#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
password required /lib/security/pam_cracklib.so

When I type in passwd, it just hangs:

Linux:[server]$ passwd
Changing password for user carls.


Anything you can think of to check?

Thanks for any help.

Carl

HI,
Can you run a strace command and see where exactly it hangs

Type

strace passwd

Instead of passwd

It will show you the system calls the command makes.
Just get some 5 lines from where the command hangs and post it.

Cheers
Z

Ahh, that was what I was looking for. I'm a Sun admin as was looking for a Linux tool that worked like ptrace. Thanks.

Oh and the problem was /etc/.pwd.lock. I saw the permission denied errors in the strace output and removed the file which fixed the problem. Weird that a file dated Jun 25, 2004 would cause intermittant problems since passwd changes would occur with no problem most of the time, just that once in a while it'd hang.

Anyway, thanks again. Sticking strace in a prominant place.

Carl

Of course the problem is, why would a suid'd passwd program be unable to write to /etc/.pwd.lock perms 600 ownership root:root?

Anybody?

Thanks again for the immediate fix.

Carl

Its not that the program was not able to write over it.
But the file was a lock and a lock has to be respected by any program till the lock is cleared by the command that created it.

Cheers
Z

Ok, that's a good point that I hadn't thought of and makes sense. So someone started passwd and the session died leaving the lock file.

Question then. Since it had a date of almost a year ago, why would any further passwd attempts work? It seemed to be either intermittent or tied to how long the system was up since rebooting seemed to resolve the problem up until this last incident.

Time to "use the source, Luke".

Thanks for the info though. Good answer.

Carl