Bug#311491: slapd: Problems solved
Package: slapd Version: 2.2.23-8 Followup-For: Bug #311491 Hi Torsten, As promised I would report back after putting the slapd system in production. We have now run it for a couple of weeks and all our problems have vanished. Thanks for your help. kind Regards, Robert -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /KNOPPIX/bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages slapd depends on: ii coreutils [fileutils] 5.2.1-2 The GNU core utilities ii debconf 1.4.50 Debian configuration management sy ii fileutils 5.2.1-2 The GNU file management utilities ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libiodbc2 3.52.2-3 iODBC Driver Manager ii libldap-2.2-7 2.2.23-8 OpenLDAP libraries ii libltdl31.5.6-6 A system independent dlopen wrappe ii libperl5.8 5.8.4-8 Shared Perl library ii libsasl22.1.19-1.5 Authentication abstraction library ii libslp1 1.0.11a-2OpenSLP libraries ii libssl0.9.7 0.9.7g-1 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.6-1 Utilities that use the proc filesy -- debconf information: * slapd/password2: (password omitted) slapd/internal/adminpw: (password omitted) * slapd/password1: (password omitted) slapd/fix_directory: true * shared/organization: salsa slapd/upgrade_slapcat_failure: * slapd/backend: BDB * slapd/allow_ldap_v2: false * slapd/no_configuration: false * slapd/move_old_database: true slapd/suffix_change: false slapd/slave_databases_require_updateref: slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/autoconf_modules: true * slapd/domain: salsa slapd/password_mismatch: slapd/invalid_config: true slapd/upgrade_slapadd_failure: slapd/dump_database: when needed slapd/migrate_ldbm_to_bdb: true * slapd/purge_database: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd: Problems solved
Hi Robert, On Tue, Aug 23, 2005 at 01:36:51PM +0200, Robert wrote: As promised I would report back after putting the slapd system in production. We have now run it for a couple of weeks and all our problems have vanished. Good to know! Thanks for your feedback. Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd
Hi Torsten, I recently concluded another series of tests with the slapd and it seems my problems have vanished. I will now include the dependencies (had to learn that one first). I am now testing on a development station on which normally after a couple of hours the machine would lock up. This did not happen so far. The only difference is that I used the dpkg-reconfigue to install a brand new ldap database + slapd.conf and imported my own ldap data using the ldif format. So making this ascii step in between the upgrading might make a difference. It could be an idea that anyone who has problems with slapd, follows this process because at least this eliminates the problem of old binary databases. I will keep slapd running on the dev machine and if the problem does not come back, I will try a production machine (an hold my breath). So far so good. When the problem comes back, I will make a new bug report because I now have the feeling that my problem had nothing to do with this thread. Also the problem with the IPv6 kernel module has vanished. So I hereby withdraw all my comments. gr. Robert Ps I might have some suggestions for the text used in the dpkg-reconfigure script, are you interested? Version: 2.2.26-3 Depends: libc6 (= 2.3.2.ds1-21), libdb4.2, libiodbc2 (= 3.52.2), libldap-2.2-7, libltdl3 (= 1.5.2-2), libperl5.8 (= 5.8.7), libsasl2 (= 2.1.19), libslp1, libssl0.9.7, libwrap0, coreutils (= 4.5.1-1) | fileutils (= 4.0i-1), psmisc, libldap-2.2-7 (= 2.2.26-3), perl ( 5.8.0) | libmime-base64-perl PreDepends: debconf (= 0.5) Recommends: db4.2-util, libsasl2-modules Suggests: ldap-utils Conflicts: umich-ldapd, ldap-server, libbind-dev, bind-dev, libltdl3 (= 1.5.4-1) Replaces: libldap2, ldap-utils ( 2.2.23-3) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd
Hi Robert, On Mon, Jul 18, 2005 at 03:58:17AM -0400, Robert de Geus wrote: Ps I might have some suggestions for the text used in the dpkg-reconfigure script, are you interested? Sure. Version: 2.2.26-3 Depends: libc6 (= 2.3.2.ds1-21), libdb4.2, libiodbc2 (= 3.52.2), libldap-2.2-7, libltdl3 (= 1.5.2-2), libperl5.8 (= 5.8.7), libsasl2 (= 2.1.19), libslp1, libssl0.9.7, libwrap0, coreutils (= 4.5.1-1) | fileutils (= 4.0i-1), psmisc, libldap-2.2-7 (= 2.2.26-3), perl ( 5.8.0) | libmime-base64-perl PreDepends: debconf (= 0.5) Recommends: db4.2-util, libsasl2-modules Suggests: ldap-utils Conflicts: umich-ldapd, ldap-server, libbind-dev, bind-dev, libltdl3 (= 1.5.4-1) Replaces: libldap2, ldap-utils ( 2.2.23-3) That's not helpful. If anything would help it's the list of your installed versions of those packages. reportbug includes them by default. Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd
Hi Torsten, We learn all the time, thanks for your advice. I hereby give you the information requested. I would like to say again, that my problem has been solved so far. I have now worked for tree days on the slapd version as stated below without any problems. Before my this workstation and or server would lock up after a couple of hours (locking up all programs requesting ldap information, if you use ldap authentication almost every program). If this persists I will test slapd on a production system. I will keep you informed. gr. Robert -- System Information: Debian Release: 3.1t APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages slapd depends on: ii coreutils [fileutils] 5.2.1-2 The GNU core utilities ii debconf 1.4.41 Debian configuration management sy ii fileutils 5.2.1-2 The GNU file management utilities ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libdb4.24.2.52-17Berkeley v4.2 Database Libraries [ ii libgcrypt11 1.2.0-10 LGPL Crypto library - runtime libr ii libgnutls11 1.0.16-9 GNU TLS library - runtime library ii libgpg-error0 1.0-1library for common error values an ii libiodbc2 3.52.1-2 iODBC Driver Manager ii libldap22.1.30-3 OpenLDAP libraries ii libltdl31.5.6-3 A system independent dlopen wrappe ii libsasl22.1.19-1.5 Authentication abstraction library ii libslp1 1.0.11-7 OpenSLP libraries ii libwrap07.6.dbs-6Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.5-1 Utilities that use the proc filesy ii zlib1g 1:1.2.2-3compression library - runtime -- debconf information: slapd/fix_directory: true * shared/organization: salsa slapd/upgrade_slapcat_failure: slapd/backend: BDB * slapd/allow_ldap_v2: false slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false slapd/slave_databases_require_updateref: slapd/autoconf_modules: true * slapd/domain: salsa slapd/password_mismatch: slapd/invalid_config: true slapd/upgrade_slapadd_failure: slapd/purge_database: false slapd/admin: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd
Hi Robert, On Wed, Jul 06, 2005 at 04:02:53PM +0200, Robert de Geus wrote: I will try to give you more info a.s.a.p. Somebody found out (hope this is true) that for a process that uses posix threat's under kernel 2.6 the process does not spawn into multiple processes. This is the same for That's the whole point of the new pthread library (NPTL). Or rather part of it ;) consistent. It is however hard to give an strace for a process which locks up the system in such a way that no other processes can start anymore. I also saw something which micht be a new bug, slapd crashes Hmm, it should be possible to overwrite nsswitch.conf on a per-user basis. Don't remember how :( Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd
Hi Torsten, I will try to give you more info a.s.a.p. Somebody found out (hope this is true) that for a process that uses posix threat's under kernel 2.6 the process does not spawn into multiple processes. This is the same for the nscd daemon as well as for slapd so this information seems consistent. It is however hard to give an strace for a process which locks up the system in such a way that no other processes can start anymore. I also saw something which micht be a new bug, slapd crashes when started if module ipV6 is loaded. If I can reproduce the bug, I will file a separate bug report. gr. Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
Hi Ulrich, On Wed, Jun 01, 2005 at 07:10:08PM +0200, Ulrich Hermisson wrote: I would be very happy with either kind of solution. Since the package, in its current state, cannot be used by us and, as I presume, many other people, it would be a big improvement if the problem were solved before the release of Debian Sarge. I will try to continue to help with this. That's unlikely to happen. And, BTW: I guess this bug is also a problem with the current linux kernel. Somebody on linux-kernel pointed out that he got 10% CPU usage by having 3 processes talk to each other in a ring inside an endless loop. For some reason the scheduler thinks that no process is ready to run. What does top say about your CPU usage? Talking about severities: We will not delay sarge because slapd has a performance problem for one user. Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
| Talking about severities: We will not delay sarge because slapd has a | performance problem for one user.=20 I guess this is a disputable decision. This makes sarge unusable for an ldap server. Our whole ldap system (a few hundred users involved) was repeatedly blocked by this bug, because of minor cpu consuming processes on that server caused by some erroneously terminated login processes to that server. We had to switch to freebsd for the ldap server because of this. Please reconsider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Thu, 2 Jun 2005, Torsten Landschoff wrote: Hi Ulrich, [...] That's unlikely to happen. And, BTW: I guess this bug is also a problem with the current linux kernel. Somebody on linux-kernel pointed out that he got 10% CPU usage by having 3 processes talk to each other in a ring inside an endless loop. For some reason the scheduler thinks that no process is ready to run. Hmm, possibly there is a problem with the scheduler itself. However, as I have written, the problem didn't show up with woody and a 2.6.7 kernel. I have applied the tag sarge because of this - why was it removed? I noticed that in all operating system configurations where the problem arises (that is, when using sarge), the slapd fails to spawn additional threads when a query is made (which it does when using woody). Maybe here something is wrong? What does top say about your CPU usage? I don't see anything conspicuous - if I start a CPU consuming process, it gets 99%, and slapd almost doesn't show up. Talking about severities: We will not delay sarge because slapd has a performance problem for one user. I am respecting your decision, of course, and I understand completely that time is short now. However, though I have not tested everything, the bug really doesn't seem to be specific to any aspect of our slapd configuration, which is simple and standard. (Please tell me if I you think that the problem doesn't arise in every slapd configuration.) And it is not just a performance problem - as I have written, the slapd needs more than 2000 x the amount of time it would need without a concurrent process. For all practical purposes: It just hangs. I didn't exaggerate to make it seem more important. Don't just believe me: This can be reproduced very easily. Best regards Ulrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
Package: slapd Version: 2.2.23-5 Severity: important The slapd almost stops working while a CPU consuming process like the one started by echo 3^ | bc is running on the same machine. That is: a query (e.g. querying a passwd database by pam_ldap) which is answered immediately (i.e. less than 1 second) if no such process is running in parallel can take more than half an hour. One can reduce it to a few minutes by increasing the priority of slapd to the maximum. If one kills the CPU consuming process, the query is answered immediately. The bug is completely reproducible, and I have also reproduced it with the newest version openldap-stable-20050429.tgz from www.openldap.org (compiled with --enable-crypt). Only when I compile with the configure option --with-threads=no, everything is ok, but the slurpd needs threads. With threads, also the test 17 performed by make test fails if a CPU consuming process is running in parallel. I have reproduced the bug on the following architectures/kernel versions (always with Debian Sarge): Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. With kind regards Ulrich Hermisson -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Versions of packages slapd depends on: ii coreutils [fileutils] 5.2.1-2 The GNU core utilities ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libiodbc2 3.52.2-3 iODBC Driver Manager ii libldap-2.2-7 2.2.23-5 OpenLDAP libraries ii libltdl31.5.6-6 A system independent dlopen wrappe ii libperl5.8 5.8.4-8 Shared Perl library ii libsasl22.1.19-1.5 Authentication abstraction library ii libslp1 1.0.11a-2OpenSLP libraries ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.5-1 Utilities that use the proc filesy -- debconf information: slapd/fix_directory: true * shared/organization: math.uni-bielefeld.de slapd/upgrade_slapcat_failure: slapd/backend: BDB * slapd/allow_ldap_v2: true slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false slapd/slave_databases_require_updateref: slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/autoconf_modules: true * slapd/domain: math.uni-bielefeld.de slapd/password_mismatch: slapd/invalid_config: true slapd/upgrade_slapadd_failure: slapd/dump_database: when needed slapd/purge_database: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Wed, Jun 01, 2005 at 12:16:05PM +0200, Ulrich Hermisson wrote: from www.openldap.org (compiled with --enable-crypt). Only when I compile with the configure option --with-threads=no, everything is ok, but the slurpd needs threads. With threads, also the test 17 performed by make test fails if a CPU consuming process is running in parallel. I have reproduced the bug on the following architectures/kernel versions (always with Debian Sarge): Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. Known problem. I'd guess the reason is that OpenLDAP is calling pthread_yield all the time. Making ldap_pvt_thread_yield a no-op might help here... Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Wed, 1 Jun 2005, Torsten Landschoff wrote: On Wed, Jun 01, 2005 at 12:16:05PM +0200, Ulrich Hermisson wrote: from www.openldap.org (compiled with --enable-crypt). Only when I compile with the configure option --with-threads=no, everything is ok, but the slurpd needs threads. With threads, also the test 17 performed by make test fails if a CPU consuming process is running in parallel. I have reproduced the bug on the following architectures/kernel versions (always with Debian Sarge): Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. Known problem. I'd guess the reason is that OpenLDAP is calling pthread_yield all the time. Making ldap_pvt_thread_yield a no-op might help here... Thank you very much! I would also think that this might help. We have, however, fixed it by using FreeBSD until the problem is solved in Debian Sarge, too. For me there seem to be just two possibilities: - The use of the scheduler functions (or whatever leads to this) must be considered wrong and harmful in at least this case. Then a fix would be something like building the package with this function disabled, just as you have proposed. - It can not be strictly considered wrong. (After all, it apparently works perfectly with Debian Woody and FreeBSD.) Then one would have to find out where the thread handling within Debian Sarge breaks this correct use of functions, and fix the bug there. I would be very happy with either kind of solution. Since the package, in its current state, cannot be used by us and, as I presume, many other people, it would be a big improvement if the problem were solved before the release of Debian Sarge. I will try to continue to help with this. With kind regards Ulrich Hermisson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
