Comment 29 for bug 270781

Ok, so the debug version of pam is installed:

# rpm -ivh pam-1.0.2-2.1debug.fc10.i386.rpm --force
Preparing... ########################################### [100%]
   1:pam ########################################### [100%]
Updating /etc/pam.d/system-auth...
#

(the other package pam-debuginfo-1.0.2-2.1debug.fc10.i386.rpm was not installed).

First case:

Having the system started from hibernate (which means the problem should still be there), using System > Lock Screen it blanks the screen, screensaver doesn't start (I've notice that in the past also, but that's not a problem anyway), leaving it a couple of seconds then pressing a key, here are the related messages in /var/log/secure:

Mar 5 20:59:50 thoth gnome-screensaver-dialog: PAM unable to dlopen(/lib/security/pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Mar 5 20:59:50 thoth gnome-screensaver-dialog: PAM adding faulty module: /lib/security/pam_ecryptfs.so
Mar 5 20:59:50 thoth gnome-screensaver-dialog: pam_unix(gnome-screensaver:account): read unix_chkpwd output error 0: Success

Indeed, there is no /lib/security/pam_ecryptfs.so file. But as you can see, no unix_chkpwd crash or debug data yet.

Second case:

Now I was rebooting the system because I was curious how come it's working at the startup.

So it's simply working as it should. Now trying again to lock the screen, of course it's working (since again, after a normal startup or reboot is working for a while), and these are the debug messages generated:

Mar 5 21:21:12 thoth gnome-screensaver-dialog: PAM unable to dlopen(/lib/security/pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Mar 5 21:21:12 thoth gnome-screensaver-dialog: PAM adding faulty module: /lib/security/pam_ecryptfs.so
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Started.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Signals set up.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Not at tty.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: User from getuidname(): snap
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Passwords read: 1
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash obtained: 0
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash verified: 7
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Password verification result: 7
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: User from getuidname(): snap
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Passwords read: 1
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash obtained: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash verified: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Password verification result: 0
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: User from getuidname(): snap

I didn't have the patience to wait for the issue to appear after reboot, so I installed
ecryptfs-utils-61-0.fc10.i386.rpm (and trousers-0.3.1-9.fc10.i386.rpm as required) in order to have
/lib/security/pam_ecryptfs.so file. Indeed, no complains about this file anymore.

Unfortunately, for now there is still no unix_chkpwd crash anymore. I'll get back to you asap in case of the next crash. I think if I don't get the issue again, then I'll install back the standard pam version. I don't think that the missing .so file influenced the crash (I'll check that later, when I'll install back again the standard pam version if the crash doesn't happen). Should I do something else?

Again, many thanks. I really appreciate your support!