On 11/01/2013 08:49 AM, Jan Tomasek wrote:
Hi Rich,

On 11/01/2013 02:22 PM, Rich Megginson wrote:
All ldapsearch scripts are executed in background = in parallel way.
But server process them in serial way. I can tell that by increasing
time needed to process ldapsearches. Increment around 2sec is caused
by pam_unix delay because of wrong password.

Is 389 bind process really serialized? Or have I just overlooked some
limit?

PAM is not thread safe, in our experience, so we have to serialize calls
into PAM.

thank you for confirmation of my observation.

In fact I'm able to put my 389 server into deadlock.

I've written simple auth script for libpam-script [1] It's purpose is to check pasword of user in other than main entry, attached.

Content of /etc/pam.d/ldapserver:
auth       required    /lib/security/pam_script.so onerr=fail dir=/usr/share/libpam-script
account    required    /lib/security/pam_script.so onerr=fail dir=/usr/share/libpam-script

[root@pdap 8445]# ls -l /usr/share/libpam-script
total 8
lrwxrwxrwx 1 root root   11 Oct 31 17:52 pam_script_acct -> perlauth.pl
lrwxrwxrwx 1 root root   11 Oct 31 17:52 pam_script_auth -> perlauth.pl
-rwxr-xr-x 1 root root 2450 Oct 31 19:45 perlauth.pl

It works fine in it's serialized way - until there is maximum 29 parallel connections.

If there is 30 or more parallel connections 389 hangs for ever. Very often killing process ldapsearch process does not help. Server is very often unable to restart so I have to kill it with -9.

Please provide a stack trace - http://port389.org/wiki/FAQ#Debugging_Hangs


My question is if there is any limit related to number of parallel bind operations. I guess there is something to related to 30 or more likely to 60 - my plugin itself open next connection to the same LDAP server.

Thanks

[1]  http://sourceforge.net/projects/pam-script/--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users