[Dovecot] Dovecot 1.0beta8 dovecot-auth consumes 100% CPU time on Solaris 10 amd64
Hello. I hope someone out there can help with this. It is getting pretty urgent.
I am running a Solaris 10 server on Opteron (amd64) hardware and have compiled Dovecot 1.0beta8 from source. It has openssl compiled in (after much mucking around with various environment variables and modifying the Makefile), and was built with: $ ./configure --with-ldap --with-ssl-dir=/etc/ssl $ make # make install
The variables: CC=/usr/sfw/bin/gcc CFLAGS='-m64 -I/usr/local/ssl/include:/usr/sfw/include:/opt/sfw/include' CPP=/usr/sfw/bin/cpp CPPFLAGS=-I/usr/local/ssl/include/openssl:/usr/sfw/include:/opt/sfw/include CXX=/usr/sfw/bin/g++ LDFLAGS='-m64 -L/usr/local/ssl/lib -R/usr/local/ssl/lib:/usr/sfw/lib:/opt/sfw/lib' LD_LIBRARY_PATH=/usr/local/ssl/lib:/usr/sfw/lib:/opt/sfw/lib
It was compiled with gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath).
I modified the SSL_CFLAGS and SSL_LIBS variables in the Makefile to make it find my openssl install in /usr/local/ssl. The one that came with the OS was broken[1], so I compiled 0.9.8b from source. The configure script for some reason didn't pick this up, even when using CFLAGS, LDFLAGS, etc.
At any rate, I successfully set it up to accept SSL/TLS connections and authenticate against an LDAP server. I use the auth_bind authentication method and only one LDAP host. I have confirmed that this works. In fact, dovecot runs just fine with the exception of the dovecot-auth proces, which is thrown into an endless loop. It starts off at maybe 1-2% CPU time, but after a few minutes it is back up to 100%.
This is the output from truss(1) pointed at the dovecot-auth process: --cut-- pollsys(0xFFFFFD7FFFDFF6F0, 5, 0xFFFFFD7FFFDFF6D0, 0x00000000) = 0 pollsys(0xFFFFFD7FFFDFF6F0, 5, 0xFFFFFD7FFFDFF6D0, 0x00000000) = 0 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFB10, 0x00000000) = 1 [same sequence repeats ad nauseum] --cut--
This is a sample of top(1) output: --cut-- load averages: 1.00, 1.00, 1.00 08:51:38 60 processes: 55 sleeping, 3 running, 1 zombie, 1 on cpu CPU states: 0.0% idle, 68.3% user, 31.7% kernel, 0.0% iowait, 0.0% swap Memory: 1024M real, 680M free, 71M swap in use, 591M swap free
PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND 22875 nobody 1 0 0 0K 0K run 726:22 99.68% dovecot-auth --cut--
Here is a condensed version of my ldap-config: (comments removed, names changed to protect the innocent) --cut-- hosts = ldap.example.com auth_bind = yes auth_bind_userdn = uid=%u,ou=People,o=example.com,o=example.com ldap_version = 3 base = uid=%,ou=People,o=example.com,o=example.com --cut--
This is my condensed dovecot.conf: --cut-- base_dir = /var/run/dovecot/ protocols = imap pop3 listen = * ssl_disable = no ssl_cert_file = /etc/ssl/certs/host.cert ssl_key_file = /etc/ssl/private/host.key ssl_cipher_list = ALL:!LOW disable_plaintext_auth = no shutdown_clients = yes log_path = /var/log/dovecot log_timestamp = "%b %d %H:%M:%S " login_user = dovecot login_process_per_connection = yes verbose_proctitle = yes verbose_ssl = yes first_valid_uid = 100 last_valid_uid = 60000 mail_debug = yes default_mail_env = maildir:/var/mail/%u/Maildir mail_full_filesystem_access = no protocol imap { login_executable = /usr/local/libexec/dovecot/imap-login mail_executable = /usr/local/libexec/dovecot/imap login_greeting_capability = yes imap_client_workarounds = outlook-idle tb-extra-mailbox-sep }
protocol pop3 { login_executable = /usr/local/libexec/dovecot/pop3-login mail_executable = /usr/local/libexec/dovecot/pop3 pop3_uidl_format = %08Xu%08Xv pop3_logout_format = top=%t/%p, retr=%r/%b, del=%d/%m, size=%s mail_plugin_dir = /usr/local/lib/dovecot/pop3 pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } auth_executable = /usr/local/libexec/dovecot/dovecot-auth auth_cache_size = 0 auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ auth_verbose = yes auth_debug = no auth default { mechanisms = plain passdb ldap { args = /usr/local/etc/dovecot-ldap.conf } userdb passwd { } user = nobody } --cut-- I may have commented out more than necessary in an attempt to be explicit while I was trying to narrow this down.
This is the output of ldd dovecot-auth: --cut-- libpam.so.1 => /lib/64/libpam.so.1 libldap.so.5 => /usr/lib/64/libldap.so.5 libsocket.so.1 => /lib/64/libsocket.so.1 libnsl.so.1 => /lib/64/libnsl.so.1 librt.so.1 => /lib/64/librt.so.1 libsendfile.so.1 => /lib/64/libsendfile.so.1 libc.so.1 => /lib/64/libc.so.1 libcmd.so.1 => /lib/64/libcmd.so.1 libsasl.so.1 => /usr/lib/64/libsasl.so.1 libmd5.so.1 => /lib/64/libmd5.so.1 libnspr4.so => /usr/lib/mps/64/libnspr4.so libplc4.so => /usr/lib/mps/64/libplc4.so libnss3.so => /usr/lib/mps/64/libnss3.so libssl3.so => /usr/lib/mps/64/libssl3.so libmp.so.2 => /lib/64/libmp.so.2 libscf.so.1 => /lib/64/libscf.so.1 libaio.so.1 => /lib/64/libaio.so.1 libpthread.so.1 => /lib/64/libpthread.so.1 libthread.so.1 => /lib/64/libthread.so.1 libdl.so.1 => /lib/64/libdl.so.1 libsoftokn3.so => /usr/lib/mps/amd64/libsoftokn3.so libplds4.so => /usr/lib/mps/amd64/libplds4.so libdoor.so.1 => /lib/64/libdoor.so.1 libuutil.so.1 => /lib/64/libuutil.so.1 libm.so.2 => /lib/64/libm.so.2 --cut--
Notes:
- The problem *seems* to occur only when I use LDAP authentication.
- Disabling SSL in the config has no effect on the CPU usage.
- I am not using NFS for anything.
- I use Thunderbird 1.5.0.2 and another client runs Outlook.
- There is no indication of any problem in the dovecot or system logs.
- I suspected this had to do with the poll method dovecot is compiled with (poll), but it happens even when I compiled it with the select method. As far as I know, none of the other methods are available on Solaris.
- I noted that the poll(2) call in Solaris will return immediately given a timeout of zero (-1 is 'forever'). I tried tacking down the use of that system call, but I had to give up on that. I only mention it in case it is a dovecot bug and of any help to Timo.
Any help is greatly appreciated.
Thank you.
- Tore
[1] If you use the factory-installed version, you get messages like "Warning: imap-login: SSL_accept() failed: error:1409D08A:SSL routines:SSL3_SETUP_KEY_BLOCK:cipher or hash unavailable" in your dovecot log.
On Wed, 2006-05-31 at 09:33 -0400, Tore André Klock wrote:
This is the output from truss(1) pointed at the dovecot-auth process: --cut-- pollsys(0xFFFFFD7FFFDFF6F0, 5, 0xFFFFFD7FFFDFF6D0, 0x00000000) = 0 pollsys(0xFFFFFD7FFFDFF6F0, 5, 0xFFFFFD7FFFDFF6D0, 0x00000000) = 0 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFB10, 0x00000000) = 1 [same sequence repeats ad nauseum] --cut--
So if pollsys() does return 1 many times a second, it means that some some connection is talking to Dovecot constantly. But if there's nothing else than pollsys() calls there, Dovecot doesn't react on it at all.. A bit difficult to guess why that would happen.
auth_bind = yes auth_bind_userdn = uid=%u,ou=People,o=example.com,o=example.com ..
- The problem *seems* to occur only when I use LDAP authentication.
Is it possible that you could try this without auth_bind to see if the bug is in it or elsewhere in LDAP authentication?
- I noted that the poll(2) call in Solaris will return immediately given a timeout of zero (-1 is 'forever').
The pollsys() parameters seem to be something completely different. I get similar values when trussing Dovecot processes which are waiting in pollsys() for a couple of seconds.
If you can't solve this in Dovecot's side, you could still use pam_ldap instead.
Is it possible that you could try this without auth_bind to see if the bug is in it or elsewhere in LDAP authentication? I switched to the mode where it will look up the hashed (in my case SHA)
Timo Sirainen wrote: password, using a single user to bind to the directory. dovecot_auth still consumes ~100% cpu time eventually, but it seemed to take longer to get there (not very scientific, I know).
Truss output looks like this, which is about the same as before: 0.0010 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1 0.0011 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690, 0x00000000) = 0 0.0011 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690, 0x00000000) = 0 0.0011 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1 0.0012 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690, 0x00000000) = 0 0.0012 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690, 0x00000000) = 0 0.0012 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1
You mentioned maybe "some connection is talking to Dovecot constantly". Is there a way I can track down what that might be? I assume you are talking about a socket, but without knowing what to look for I can't see anything unusual in the netstat output.
If you can't solve this in Dovecot's side, you could still use pam_ldap instead. Unfortunately I'm new to Solaris, so it will take me a little longer to test that.
Thank you for your remarkably quick response. I will look into setting up PAM as you suggested.
- Tore
On May 31, 2006, at 6:26 PM, Tore André Klock wrote:
Truss output looks like this, which is about the same as before: 0.0010 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1 0.0011 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690,
0x00000000) = 0 0.0011 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690,
0x00000000) = 0 0.0011 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1 0.0012 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690,
0x00000000) = 0 0.0012 pollsys(0xFFFFFD7FFFDFF6B0, 5, 0xFFFFFD7FFFDFF690,
0x00000000) = 0 0.0012 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAD0, 0x00000000) = 1
The one strange thing here is that there seem to be two different poll
() calls somewhere doing different things. If this is the case, the
only place where this could happen is in PostgreSQL code. You haven't
configured and enabled that also, right? :)
You mentioned maybe "some connection is talking to Dovecot
constantly". Is there a way I can track down what that might be? I assume you are
talking about a socket, but without knowing what to look for I can't see anything
unusual in the netstat output.
Give -v pollsys parameters to truss. It shows what fd it is that's
returning something all the time. Looks like in the one Solaris
system I have you can get a list of file descriptors by looking at /
proc/pid/fd/ directory contents. But I don't know how you could know
where the sockets are connected to.
Timo Sirainen wrote:
On May 31, 2006, at 6:26 PM, Tore André Klock wrote: The one strange thing here is that there seem to be two different poll() calls somewhere doing different things. If this is the case, the only place where this could happen is in PostgreSQL code. You haven't configured and enabled that also, right? :) No, I only added --with-ldap. I don't believe I have any SQL enabled. I don't even think PostgresSQL is even installed.
Give -v pollsys parameters to truss. It shows what fd it is that's returning something all the time. Looks like in the one Solaris system I have you can get a list of file descriptors by looking at /proc/pid/fd/ directory contents. But I don't know how you could know where the sockets are connected to. Here is the output after I re-enabled the ldap setup: ---cut---- Base time stamp: 1149091594.7831 [ Wed May 31 12:06:34 EDT 2006 ] 0.0010 pollsys(0xFFFFFD7FFFDFF6C0, 5, 0xFFFFFD7FFFDFF6A0, 0x00000000) = 0 fd=8 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.000000000 sec 0.0011 pollsys(0xFFFFFD7FFFDFF6C0, 5, 0xFFFFFD7FFFDFF6A0, 0x00000000) = 0 fd=8 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.000000000 sec 0.0012 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAE0, 0x00000000) = 1 fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI fd=0 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=3 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=9 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=10 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=11 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=12 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=13 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=14 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 timeout: 0.575000000 sec 0.0013 pollsys(0xFFFFFD7FFFDFF6C0, 5, 0xFFFFFD7FFFDFF6A0, 0x00000000) = 0 fd=8 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.000000000 sec 0.0014 pollsys(0xFFFFFD7FFFDFF6C0, 5, 0xFFFFFD7FFFDFF6A0, 0x00000000) = 0 fd=8 ev=POLLIN rev=0 fd=-1 ev=0 rev=0 ...last pollfd structure repeated 3 times... timeout: 0.000000000 sec 0.0014 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAE0, 0x00000000) = 1 fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN|POLLPRI fd=0 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=3 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=9 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=10 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=11 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=12 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=13 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=14 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 timeout: 0.575000000 sec ---cut----
/proc/pid/fd only gives me a list of the file descriptions: ---cut--- s--------- 0 root root 0 May 31 12:06 0 c--------- 1 root sys 13, 2 May 31 12:00 1 s--------- 0 root root 0 May 31 12:06 10 s--------- 0 root root 0 May 31 12:06 11 s--------- 0 root root 0 May 31 12:06 12 s--------- 0 root root 0 May 31 12:06 13 s--------- 0 root root 0 May 31 12:08 14 s--------- 0 root root 0 May 31 12:08 15 p--------- 0 root root 0 May 31 12:08 2 s--------- 0 root root 0 May 31 12:06 3 c--------- 1 root sys 149, 1 May 31 08:41 4 p--------- 0 root root 0 May 31 12:06 5 p--------- 0 root root 0 May 31 12:06 6 D--------- 1 root root 0 May 12 10:52 7 s--------- 0 root root 0 May 31 12:08 8 s--------- 0 root root 0 May 31 12:06 9 ---cut---
/proc/pid/path gives me: ---cut--- lrwxrwxrwx 1 root root 0 May 31 12:06 0 lrwxrwxrwx 1 root root 0 May 31 12:06 1 -> /devices/pseudo/mm@0:null lrwxrwxrwx 1 root root 0 May 31 12:06 10 lrwxrwxrwx 1 root root 0 May 31 12:06 11 lrwxrwxrwx 1 root root 0 May 31 12:06 12 lrwxrwxrwx 1 root root 0 May 31 12:06 13 lrwxrwxrwx 1 root root 0 May 31 12:06 15 lrwxrwxrwx 1 root root 0 May 31 12:06 2 lrwxrwxrwx 1 root root 0 May 31 12:06 3 lrwxrwxrwx 1 root root 0 May 31 12:06 4 -> /devices/pseudo/random@0:urandom lrwxrwxrwx 1 root root 0 May 31 12:06 5 lrwxrwxrwx 1 root root 0 May 31 12:06 6 lrwxrwxrwx 1 root root 0 May 31 12:06 7 -> /var/run/name_service_door lrwxrwxrwx 1 root root 0 May 31 12:06 8 lrwxrwxrwx 1 root root 0 May 31 12:06 9 lrwxrwxrwx 1 root root 0 May 31 12:06 a.out -> /usr/local/libexec/dovecot/dovecot-auth lrwxrwxrwx 1 root root 0 May 31 12:06 cwd -> /var/run/dovecot lrwxrwxrwx 1 root root 0 May 31 12:06 root -> / lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12509 -> /usr/lib/mps/amd64/libnspr4.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12510 -> /usr/lib/mps/amd64/libplc4.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12511 -> /usr/lib/mps/amd64/libplds4.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12527 -> /usr/lib/mps/amd64/libnss3.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12531 -> /usr/lib/mps/amd64/libsoftokn3.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.12532 -> /usr/lib/mps/amd64/libssl3.so lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.2103 -> /usr/lib/amd64/libldap.so.5 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.2298 -> /lib/amd64/libmd5.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3883 -> /lib/amd64/ld.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3885 -> /lib/amd64/libaio.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3888 -> /lib/amd64/libc.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3890 -> /lib/amd64/libcmd.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3898 -> /lib/amd64/libdl.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3899 -> /lib/amd64/libdoor.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3910 -> /lib/amd64/libmp.so.2 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3911 -> /lib/amd64/libnsl.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3913 -> /lib/amd64/libpam.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3915 -> /lib/amd64/libpthread.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3919 -> /lib/amd64/librt.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3922 -> /lib/amd64/libscf.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3925 -> /lib/amd64/libsendfile.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3926 -> /lib/amd64/libsocket.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3928 -> /lib/amd64/libthread.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.3931 -> /lib/amd64/libuutil.so.1 lrwxrwxrwx 1 root root 0 May 31 12:06 ufs.85.1.4566 -> /usr/lib/amd64/libsasl.so.1 ---cut---
I configured dovecot to use straight PAM (unix authentication - still working on the LDAP part), and dovecot-auth plays nice then. Looks like that may be a workable fallback if the builtin won't work.
Thanks again,
- Tore
On May 31, 2006, at 7:16 PM, Tore André Klock wrote:
Timo Sirainen wrote:
On May 31, 2006, at 6:26 PM, Tore André Klock wrote: The one
strange thing here is that there seem to be two different poll() calls somewhere
doing different things. If this is the case, the only place where this
could happen is in PostgreSQL code. You haven't configured and enabled that
also, right? :) No, I only added --with-ldap. I don't believe I have any SQL
enabled. I don't even think PostgresSQL is even installed.
Actually I think it's probably some of LDAP's internal code.
0.0012 pollsys(0x00467DC0, 10, 0xFFFFFD7FFFDFFAE0, 0x00000000) = 1 fd=5 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=0 fd=1 ev=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL rev=POLLIN| POLLPRI
fd=1 gives input? That really shouldn't be happening. fd 1 should be / dev/null. It shouldn't even be polling it..
lrwxrwxrwx 1 root root 0 May 31 12:06 1 -> /devices/ pseudo/mm@0:null
So it is /dev/null.. What if you add the attached patch, does it
crash then instead? If yes, it looks like a bug in the LDAP library..
Or is it possible that you have the same problem as this other guy
who compiled Dovecot with one LDAP's header files but actually used
another LDAP's library? Looking at your original mail you seemed to
have given correct flags, but maybe it still was using Solaris LDAP's
header file?
Timo Sirainen wrote:
So it is /dev/null.. What if you add the attached patch, does it crash then instead? If yes, it looks like a bug in the LDAP library.. It starts and then crashes with these entries in the log: dovecot: May 31 12:43:31 Info: Dovecot v1.0.beta8 starting up dovecot: May 31 12:43:32 Error: auth(default): file db-ldap.c: line 276 (db_ldap_connect): assertion failed: (fd != 1) dovecot: May 31 12:43:33 Error: Auth process died too early - shutting down dovecot: May 31 12:43:33 Error: child 27086 (auth) killed with signal 6
Or is it possible that you have the same problem as this other guy who compiled Dovecot with one LDAP's header files but actually used another LDAP's library? Looking at your original mail you seemed to have given correct flags, but maybe it still was using Solaris LDAP's header file? Anything is possible.
My Makefile (in src and src/auth) shows this: AUTH_CFLAGS = AUTH_LIBS = -lpam -lldap [...] CC = /usr/sfw/bin/gcc CCDEPMODE = depmode=gcc3 CFLAGS = -std=gnu99 -m64 -I/usr/local/ssl/include:/usr/sfw/include:/opt/sfw/include -Wall -W -Wmissing-prototypes -Wmissing-declarat ions -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -I/usr/sfw/include CPP = /usr/sfw/bin/cpp CPPFLAGS = -I/usr/local/ssl/include/openssl:/usr/sfw/include:/opt/sfw/include CXX = /usr/sfw/bin/g++ CXXCPP = /usr/sfw/bin/g++ -E CXXDEPMODE = depmode=gcc3 CXXFLAGS = -g -O2
Maybe I need to manually change AUTH_CFLAGS?
Thanks,
- Tore
On Wed, 2006-05-31 at 12:50 -0400, Tore André Klock wrote:
Timo Sirainen wrote:
So it is /dev/null.. What if you add the attached patch, does it crash then instead? If yes, it looks like a bug in the LDAP library.. It starts and then crashes with these entries in the log: dovecot: May 31 12:43:31 Info: Dovecot v1.0.beta8 starting up dovecot: May 31 12:43:32 Error: auth(default): file db-ldap.c: line 276 (db_ldap_connect): assertion failed: (fd != 1)
Did you figure this out yet? This assert really shouldn't have happened, so I think this is the problem:
Or is it possible that you have the same problem as this other guy who compiled Dovecot with one LDAP's header files but actually used another LDAP's library? Looking at your original mail you seemed to have given correct flags, but maybe it still was using Solaris LDAP's header file? . Anything is possible.
My Makefile (in src and src/auth) shows this: AUTH_CFLAGS = AUTH_LIBS = -lpam -lldap [...] CC = /usr/sfw/bin/gcc CCDEPMODE = depmode=gcc3 CFLAGS = -std=gnu99 -m64 -I/usr/local/ssl/include:/usr/sfw/include:/opt/sfw/include -Wall -W -Wmissing-prototypes -Wmissing-declarat ions -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -I/usr/sfw/include CPP = /usr/sfw/bin/cpp CPPFLAGS = -I/usr/local/ssl/include/openssl:/usr/sfw/include:/opt/sfw/include
Does this mean it first looks at openssl and then the others, or the other way around? I've never used -Ia:b:c format.
Maybe I need to manually change AUTH_CFLAGS?
Don't know really..
participants (2)
-
Timo Sirainen
-
Tore André Klock