Hello,
I am fairly new to Dovecot, so please forgive me if I am missing
something obvious here.  I have checked the archived dovecot mailing
list messages and have Googled for everything I can think of, and I
still have not found anything to help me solve this problem.  I am
running Postfix+Postgresql+Dovecot on my Fedora FC2 box.  I have
compiled both Postfix and Dovecot from source.  I believe I have postfix
running properly.  No error messages show up in my logs when starting
Postfix or Dovecot.  Messages are being delivered by Postfix just fine:
        Dec 12 11:45:42 co-nundrum postfix/virtual[15759]: 15E82F8EF0:
        to=<jaeson at domain.name>, relay=virtual, delay=1, status=sent
        (delivered to maildir)
However, when I try to login to Dovecot over IMAP I get an "Internal
login failure" error:
        [jaeson at localhost jaeson]$ telnet co-nundrum imap
        Trying 207.7.137.6...
        Connected to co-nundrum.
        Escape character is '^]'.
        * OK dovecot ready.
        1 LOGIN jaeson secret
        1 OK Logged in.
        * BYE Internal login failure. Error report written to server
        log.
        Connection closed by foreign host.
When I check the dovecot log file I see the following entries:
        dovecot-auth: Dec 12 01:15:59 Info: PGSQL: Performing query:
        SELECT password FROM user_accounts WHERE username='jaeson'
        imap-login: Dec 12 01:15:59 Info: Internal login failure: jaeson
        [66.159.231.21]
        dovecot: Dec 12 01:15:59 Error: child 9845 (auth) killed with
        signal 11
Here are the entries from my dovecot.conf file.  As you can see, I have
set both auth_verbose and auth_debug = yes, but I don't seem to be
getting any log messages with enough verbosity to indicate just what the
problem is.
        base_dir = /var/run/dovecot/
        protocols = imap imaps pop3 pop3s
        imap_listen = *
        pop3_listen = *
        ssl_parameters_regenerate = 24
        disable_plaintext_auth = no
        log_path = /var/log/dovecot.log
        info_log_path = /var/log/dovecot.log
        login_dir = /var/run/dovecot-login
        login = imap
        login_executable = /usr/libexec/dovecot/imap-login
        login_user = dovecot
        login_process_size = 16
        login_process_per_connection = yes
        login_processes_count = 3
        login_max_processes_count = 128
        login_max_logging_users = 256
        max_mail_processes = 1024
        verbose_proctitle = yes
        verbose_ssl = yes
        first_valid_uid = 5000
        last_valid_uid = 65535
        first_valid_gid = 5000
        last_valid_gid = 65535
        default_mail_env = maildir:/mail/%d/%u
        mail_save_crlf = yes
        maildir_copy_with_hardlinks = no
        maildir_check_content_changes = no
        mbox_locks = fcntl
        umask = 0077
        imap_executable = /usr/libexec/dovecot/imap
        imap_process_size = 256
        auth = default
        auth_mechanisms = plain
        auth_userdb = pgsql /etc/dovecot-pgsql.conf
        auth_passdb = pgsql /etc/dovecot-pgsql.conf
        auth_executable = /usr/libexec/dovecot/dovecot-auth
        auth_user = root
        auth_count = 1
        auth_username_chars        
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
        auth_verbose = yes
        auth_debug = yes
Additionally, here are the entries in my dovecot-pgsql.conf file:
        
        connect = host=localhost dbname=mail_DB user=mailreader
        password=secret
        default_pass_scheme = PLAIN
        password_query = SELECT password FROM user_accounts WHERE
        username='%u'
        user_query = SELECT '/mail/'||mailbox AS home, uid, gid FROM
        user_accounts WHERE username='%u'
Finally, here is the configure command I used when building Dovecot from
source:
        ./configure --prefix=/usr --enable-debug --with-pgsql
        --with-cyrus-sasl2 --with-ssl=openssl --sysconfdir=/etc
At this point, I think that the connections to my postgresql tables are
all working properly, and the initial authentication with Dovecot
appears to be working.  Dovecot *does* accept my password and gives me
the "OK Logged in." response message, but somewhere before it kicks
off
the IMAP process it dies with a SIGSEGV.  Perhaps I have some file
permissions out of whack?  Has anyone else encountered this problem, or
perhaps has any insight into what might be going wrong or how to find
out more information?
Thanks,
Jaeson Schultz
jaeson at jaeson dot net
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20041212/50d9a95d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20041212/50d9a95d/attachment-0001.bin>
Jaeson, While you have been delightfuly thorough with providing information related to your problem, you appear to have neglected to mention which version of Dovecot you are using. I'm sure the list would like to know. I don't use SQL based user auth, so I can't help much there, though it all looks ok to me.> > Finally, here is the configure command I used when building Dovecot from > source: > > > ./configure --prefix=/usr --enable-debug --with-pgsql > --with-cyrus-sasl2 --with-ssl=openssl --sysconfdir=/etc >Why have you put "--with-cyrus-sasl2"? Last I heard that wasn't working, and even if it was, I've never heard good things about it. Dovecot has its own SASL implementation, which by most reports is very good.> > At this point, I think that the connections to my postgresql tables are > all working properly, and the initial authentication with Dovecot > appears to be working. Dovecot *does* accept my password and gives me > the "OK Logged in." response message, but somewhere before it kicks off > the IMAP process it dies with a SIGSEGV. Perhaps I have some file > permissions out of whack? Has anyone else encountered this problem, or > perhaps has any insight into what might be going wrong or how to find > out more information? >I do recall some messages on the list recently about recent patches unbreaking DB connections. Of course, this would depend on which version of Dovecot you are running. -- Curtis Maloney
On 12.12.2004, at 23:08, Jaeson Schultz wrote:> dovecot: Dec 12 01:15:59 Error: child 9845 (auth) killed with signal > 11So, this is the real problem. For some reason it crashes before doing userdb lookup. gdb backtrace from this would be helpful. Easiest way to do this would be: gdb /usr/local/libexec/dovecot/dovecot-auth `pidof dovecot-auth` cont <wait for crash> bt full and mail it to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20041213/7b77d930/attachment-0001.bin>
Hello, I should have sent my first message in plain text instead of HTML so it would show up better in the list archives. Anyhow, I am using the latest release of Dovecot, v0.99.12.1. Seeing as how I don't need the cyrus-sasl2 to be compiled in, I have just rebuilt dovecot without it. Unfortunately I am still getting the same results... [jaeson at shell01 ~]$ telnet co-nundrum imap Trying 207.7.137.6... Connected to co-nundrum. Escape character is '^]'. * OK dovecot ready. 1 LOGIN jaeson secret 1 OK Logged in. * BYE Internal login failure. Error report written to server log. Connection closed by foreign host. The dovecot logs still indicate an "Internal login failure", but offers no extra explanation as to why. dovecot-auth: Dec 13 11:43:04 Info: PGSQL: Performing query: SELECT password FROM user_accounts WHERE username='jaeson' imap-login: Dec 13 11:43:04 Info: Internal login failure: jaeson [216.39.112.19] dovecot: Dec 13 11:43:04 Error: child 25784 (auth) killed with signal 11 I am wondering that since I see the auth_passdb query, shouldn't I also be seeing a log entry for the auth_userdb query as well, or does this happen once the imap process is started? Any advice for how to track down the source of the problem is appreciated. ~Jaeson [This E-mail scanned for viruses]
[root at co-nundrum root]# gdb /usr/local/libexec/dovecot/dovecot-auth 26340
GNU gdb Red Hat Linux (6.0post-0.20040223.19rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as
"i386-redhat-linux-gnu".../usr/local/libexec/dovecot/dovecot-auth: No
such
file or directory.
Attaching to process 26340
Reading symbols from /usr/libexec/dovecot/dovecot-auth...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libpam.so.0...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /usr/lib/libpq.so.3...done.
Loaded symbols for /usr/lib/libpq.so.3
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /usr/lib/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libk5crypto.so.3...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libssl.so.4...done.
Loaded symbols for /lib/libssl.so.4
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/tls/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread -151047520 (LWP 26340)]
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
0x00a4f7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -151047520 (LWP 26340)]
0x00ac93d4 in _int_free () from /lib/tls/libc.so.6
(gdb) bt full
#0  0x00ac93d4 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#1  0x00aca72b in free () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0805495e in i_free (mem=0x97dfe28) at imem.c:37
No locals.
#3  0x08051554 in pgsql_lookup_pass (auth_request=0x97dfc30,
pgsql_request=0xb7ffdc) at passdb-pgsql.c:117
        conn = (struct pgsql_connection *) 0x97dfe28
        query = 0x9800000 <Address 0x9800000 out of bounds>
        str = (string_t *) 0xb81760
#4  0x0804f723 in mech_plain_auth_continue (auth_request=0x97dfc30,
request=0x9800000, data=0x97dfe20 "", callback=0x9800000) at
mech-plain.c:68
        authenid = 0x97d9509 "jaeson"
        pass = 0x97bb060 "secret"
        i = 131553
        count = 2
#5  0x0804f05e in mech_request_continue (conn=0x97d4e00, request=0xfeea6dc0,
data=0x97d9508 "", callback=0x804de34 <request_callback>) at
mech.c:121
        auth_request = (struct auth_request *) 0x97dfc30
#6  0x0804dffe in login_input_request (conn=0x97d4e00) at
login-connection.c:138
        request = {type = AUTH_LOGIN_REQUEST_CONTINUE, id = 1, data_size 15}
        data = (unsigned char *) 0x97d9508 ""
        size = 27
#7  0x080560cc in io_loop_handler_run (ioloop=0x97bfd40) at
ioloop-poll.c:214
        data = (struct ioloop_handler_data *) 0x97bfd60
        pollfd = (struct pollfd *) 0x97bfd98
        tv = {tv_sec = 2, tv_usec = 446220}
        io = (struct io *) 0x97d4f30
        io_p = (struct io **) 0x97cf840
        t_id = 2
        msecs = 159383552
        ret = 0
        call = 1
#8  0x08055b69 in io_loop_run (ioloop=0x97bfd40) at ioloop.c:259
No locals.
#9  0x0804e610 in main (argc=1, argv=0xfeea6ef4) at main.c:121
No locals.
-----Original Message-----
From: Timo Sirainen [mailto:tss at iki.fi] 
Sent: Monday, December 13, 2004 11:52 AM
To: Jaeson Schultz
Cc: dovecot at dovecot.org
Subject: Re: [Dovecot] Internal login failure
On 12.12.2004, at 23:08, Jaeson Schultz wrote:
>  dovecot: Dec 12 01:15:59 Error: child 9845 (auth) killed with signal
> 11
So, this is the real problem. For some reason it crashes before doing 
userdb lookup. gdb backtrace from this would be helpful. Easiest way to 
do this would be:
gdb /usr/local/libexec/dovecot/dovecot-auth `pidof dovecot-auth` cont <wait
for crash> bt full
and mail it to me.
[This E-mail scanned for viruses]
I have discovered an odd problem; some users are able to connect to 
Dovecot either via pop3 or imap without any problems. Other users, however, 
aren't, and the following message appears in /var/log/mail.log:
---
dovecot-auth: Login process 13 connected
dovecot-auth: Login process 13 sent handshake: PID 1313
pop3-login: Internal login failure: user at mydomain.tld [195.242.16.30]
dovecot: child 1311 (auth) killed with signal 11
---
I'm using Dovecot 0.99.11 (Debian Sarge), and all user information is stored
in an LDAP database. Any suggestions?
    Thanks,
    :Peter