Re: [Dovecot] Dovecot Authentication Problem - Help pls!
On Mon, 2007-06-04 at 16:27 +0300, Odhiambo WASHINGTON wrote: > -bash-2.05b$ sudo su > Password: > [EMAIL PROTECTED] ax | grep dove > 43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot > 43803 ?? S 0:00.05 dovecot-auth > [EMAIL PROTECTED] attach 43803 > GNU gdb 4.18 (FreeBSD) > Copyright 1998 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-unknown-freebsd"... > > attach: No such file or directory. Oh, so BSD needs to have the path specified. I knew the "attach" wasn't really correct or meaningful, but I've been using it anyway. So the correct way would be gdb /usr/local/libexec/dovecot/dovecot-auth 43803 > # At this point, I go to another shell where I attempt pop3 login. > The login fails with an error, of course. > > Now, what am I supposed to type/do on the gdb shell? > As you can see, it has the word "Continuing"... anything I need to type > to get it our of that so that it again accepts my commands? dovecot-auth process should have crashed and gdb dropped back to accepting commands. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot Authentication Problem - Help pls! - RESOLVED
On Tuesday June 05, 2007 at 10:51:04 (AM) Dominic Marks wrote:
> Odhiambo WASHINGTON wrote:
> > * On 04/06/07 16:27 +0300, Wash wrote:
> > | * On 04/06/07 15:16 +0300, Timo Sirainen wrote:
> > | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote:
> > | | > I have built and manually copied dovecot-auth to the install
> > destination
> > | | > and now it id not stripped. Now this is the result of the debug:
> > | | ..
> > | | > #0 0x805d848 in sql_query_get_result ()
> > | | > (gdb) bt
> > | |
> > | | Now this backtrace looks correct, but it's still stripped. Otherwise
> > it
> > | | would have shown parameters inside the ().
> > |
> > | Oh, so do I need to build everything unstripped? That would be difficult
> > | when using the ports.
> > |
>
> Let me help you then! :-)
>
> cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install
>
> Will install an unstripped Dovecot. If you use portupgrade you can set
> these are MAKE_ARGS in pkgtools.conf if you want to always have one
> available.
You could also go this route.
Look at /usr/ports/Mk/bsd.port.mk in this section:
.if defined(WITH_DEBUG) && !defined(WITHOUT_DEBUG)
STRIP= #none
STRIP_CMD= ${TRUE}
DEBUG_FLAGS?= -g
CFLAGS:=${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
.endif
As you can see, if WITH_DEBUG is defined, then $STRIP will be a empty,
DEBUG_FLAGS and CFLAGS changes too.
Simply set 'WITH_DEBUG=yes' in the environment on on the command line.
I also set 'DEBUG_FLAGS=-ggdb3' which supplies slightly more output.
That is of course your call. It is important to realize that the
default is "CFLAGS=-O2 -fno-strict-aliasing -pipe". You need to change
the '02' to '0' or to insure that proper debug information is
available at run time. Using the 'WITH_DEBUG=yes' accomplishes that
objective.
HTH
--
Gerard
DISCLAIMER
If you find a posting or message from me
offensive, inappropriate, or disruptive,
please ignore it. If you don't know how to
ignore a posting, complain to me and I will
be only too happy to demonstrate... ;-)
Re: [Dovecot] Dovecot Authentication Problem - Help pls! - RESOLVED
* On 05/06/07 15:51 +0100, Dominic Marks wrote: | Odhiambo WASHINGTON wrote: | > * On 04/06/07 16:27 +0300, Wash wrote: | > | * On 04/06/07 15:16 +0300, Timo Sirainen wrote: | > | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: | > | | > I have built and manually copied dovecot-auth to the install | > destination | > | | > and now it id not stripped. Now this is the result of the debug: | > | | .. | > | | > #0 0x805d848 in sql_query_get_result () | > | | > (gdb) bt | > | | | > | | Now this backtrace looks correct, but it's still stripped. Otherwise | > it | > | | would have shown parameters inside the (). | > | | > | Oh, so do I need to build everything unstripped? That would be difficult | > | when using the ports. | > | | | Let me help you then! :-) | | cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install | | Will install an unstripped Dovecot. If you use portupgrade you can set | these are MAKE_ARGS in pkgtools.conf if you want to always have one | available. Wow! Thanks for that tip! Kept for future reference. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ "Spare no expense to save money on this one." -- Samuel Goldwyn smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] Dovecot Authentication Problem - Help pls! - RESOLVED
Odhiambo WASHINGTON wrote: > * On 04/06/07 16:27 +0300, Wash wrote: > | * On 04/06/07 15:16 +0300, Timo Sirainen wrote: > | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: > | | > I have built and manually copied dovecot-auth to the install > destination > | | > and now it id not stripped. Now this is the result of the debug: > | | .. > | | > #0 0x805d848 in sql_query_get_result () > | | > (gdb) bt > | | > | | Now this backtrace looks correct, but it's still stripped. Otherwise > it > | | would have shown parameters inside the (). > | > | Oh, so do I need to build everything unstripped? That would be difficult > | when using the ports. > | Let me help you then! :-) cd /usr/ports/mail/dovecot && make CFLAGS+=-g STRIP= install Will install an unstripped Dovecot. If you use portupgrade you can set these are MAKE_ARGS in pkgtools.conf if you want to always have one available. Dominic
Re: [Dovecot] Dovecot Authentication Problem - Help pls! - RESOLVED
* On 04/06/07 16:27 +0300, Wash wrote: | * On 04/06/07 15:16 +0300, Timo Sirainen wrote: | | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: | | > I have built and manually copied dovecot-auth to the install destination | | > and now it id not stripped. Now this is the result of the debug: | | .. | | > #0 0x805d848 in sql_query_get_result () | | > (gdb) bt | | | | Now this backtrace looks correct, but it's still stripped. Otherwise it | | would have shown parameters inside the (). | | Oh, so do I need to build everything unstripped? That would be difficult | when using the ports. | | | | Did you build manually from the tarball or using ports? | | From the ports! | | | | Building it with -g and without -O2 would be the best way to | | debug this properly. I don't know about ports, but using | | tarball you're able to do this with: | | | | CFLAGS=-g ./configure | | | | Once you do get the sql_query_get_result() to show a bit more | | information, type also these: | | | | p i | | p fields_count | | p name | | p value | | p *auth_result | | | I do believe this problem is something to do with the OS version on | which it is happening, and perhaps might be so difficult to get round | to solving. All this is happening on FreeBSD 4.11, with MySQL-4.0.27. | This system could be "dirty" - some stale libscould be lying around! | | I have simulated a similar setup on FreeBSD 5.5 and 6.2 both using | MySQL-4.1.22, and FreeBSD 7.x using MySQL-5.0.41 and there is no | crash at all. I create a file hierarchy for the mail_location and | everything seems to work perfectly. | | The only problem I am facing is that the actual mail_store that I | need to move to another server via imapsync does live on the | FreeBSD 4.11 box! | | It would be nice to get to solve this problem, as that would make | life easy for me, but now I am beginning to think that I could as | well rsync the data onto another machine and access it from there. | NFS-mounting the mail store would be another option but I hate to | deal with NFS-related problems too:-) | | | | > While trying the other method you have detailed, I just don't seem to get it right: | | > | | > [EMAIL PROTECTED] ax | grep dove | | > 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot | | > 11447 ?? S 0:00.02 dovecot-auth | | > 17279 p2 RV 0:00.00 grep dove (csh) | | > | | > [EMAIL PROTECTED] attach 11447 -w process | | | | I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth | | -w" process. Apparently it hasn't been started yet. You could do a login | | with invalid user/pass to make sure it's created but without getting it | | to crash. But this isn't really needed since you managed to get a | | noncorrupted backtrace anyway using the core. | | Ok. Allow me to understand this, even if just for another day.. | | -bash-2.05b$ sudo su | Password: | [EMAIL PROTECTED] ax | grep dove | 43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot | 43803 ?? S 0:00.05 dovecot-auth | [EMAIL PROTECTED] attach 43803 | GNU gdb 4.18 (FreeBSD) | Copyright 1998 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-unknown-freebsd"... | | attach: No such file or directory. | | | /mailstore/home/wash/43803: No such file or directory. | Attaching to process 43803 | 0x2812bc50 in ?? () | (gdb) cont | Continuing. | | # At this point, I go to another shell where I attempt pop3 login. | The login fails with an error, of course. | | Now, what am I supposed to type/do on the gdb shell? | As you can see, it has the word "Continuing"... anything I need to type | to get it our of that so that it again accepts my commands? While still waiting for clarification so that I get to have ideas how developers debug crashes, I got round to solving this problem on FreeBSD 4.11. It turns out that dovecot-auth was linking against an old library of libmysqlclient that was lying somewhere in /usr/local/lib/compat/pkg. I am not sure what created that libs container, but all I had to do was to make a symlink to the correct library inside this container, rebuild dovecot from the ports and voila! No more dovecot-auth crashes. Thanks, Timo, for your time on trying to help me with this. I am awaiting your answers to the questions above - on gdb. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_)
Re: [Dovecot] Dovecot Authentication Problem - Help pls!
* On 04/06/07 15:16 +0300, Timo Sirainen wrote: | On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: | > I have built and manually copied dovecot-auth to the install destination | > and now it id not stripped. Now this is the result of the debug: | .. | > #0 0x805d848 in sql_query_get_result () | > (gdb) bt | | Now this backtrace looks correct, but it's still stripped. Otherwise it | would have shown parameters inside the (). Oh, so do I need to build everything unstripped? That would be difficult when using the ports. | Did you build manually from the tarball or using ports? From the ports! | Building it with -g and without -O2 would be the best way to | debug this properly. I don't know about ports, but using | tarball you're able to do this with: | | CFLAGS=-g ./configure | | Once you do get the sql_query_get_result() to show a bit more | information, type also these: | | p i | p fields_count | p name | p value | p *auth_result I do believe this problem is something to do with the OS version on which it is happening, and perhaps might be so difficult to get round to solving. All this is happening on FreeBSD 4.11, with MySQL-4.0.27. This system could be "dirty" - some stale libscould be lying around! I have simulated a similar setup on FreeBSD 5.5 and 6.2 both using MySQL-4.1.22, and FreeBSD 7.x using MySQL-5.0.41 and there is no crash at all. I create a file hierarchy for the mail_location and everything seems to work perfectly. The only problem I am facing is that the actual mail_store that I need to move to another server via imapsync does live on the FreeBSD 4.11 box! It would be nice to get to solve this problem, as that would make life easy for me, but now I am beginning to think that I could as well rsync the data onto another machine and access it from there. NFS-mounting the mail store would be another option but I hate to deal with NFS-related problems too:-) | > While trying the other method you have detailed, I just don't seem to get it right: | > | > [EMAIL PROTECTED] ax | grep dove | > 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot | > 11447 ?? S 0:00.02 dovecot-auth | > 17279 p2 RV 0:00.00 grep dove (csh) | > | > [EMAIL PROTECTED] attach 11447 -w process | | I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth | -w" process. Apparently it hasn't been started yet. You could do a login | with invalid user/pass to make sure it's created but without getting it | to crash. But this isn't really needed since you managed to get a | noncorrupted backtrace anyway using the core. Ok. Allow me to understand this, even if just for another day.. -bash-2.05b$ sudo su Password: [EMAIL PROTECTED] ax | grep dove 43802 ?? Ss 0:00.08 /usr/local/sbin/dovecot 43803 ?? S 0:00.05 dovecot-auth [EMAIL PROTECTED] attach 43803 GNU gdb 4.18 (FreeBSD) Copyright 1998 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-unknown-freebsd"... attach: No such file or directory. /mailstore/home/wash/43803: No such file or directory. Attaching to process 43803 0x2812bc50 in ?? () (gdb) cont Continuing. # At this point, I go to another shell where I attempt pop3 login. The login fails with an error, of course. Now, what am I supposed to type/do on the gdb shell? As you can see, it has the word "Continuing"... anything I need to type to get it our of that so that it again accepts my commands? -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ All the passions make us commit faults; love makes us commit the most ridiculous ones. -- La Rochefoucauld
Re: [Dovecot] Dovecot Authentication Problem - Help pls!
On Mon, 2007-06-04 at 09:02 +0300, Odhiambo WASHINGTON wrote: > I have built and manually copied dovecot-auth to the install destination > and now it id not stripped. Now this is the result of the debug: .. > #0 0x805d848 in sql_query_get_result () > (gdb) bt Now this backtrace looks correct, but it's still stripped. Otherwise it would have shown parameters inside the (). Did you build manually from the tarball or using ports? Building it with -g and without -O2 would be the best way to debug this properly. I don't know about ports, but using tarball you're able to do this with: CFLAGS=-g ./configure Once you do get the sql_query_get_result() to show a bit more information, type also these: p i p fields_count p name p value p *auth_result > While trying the other method you have detailed, I just don't seem to get it > right: > > [EMAIL PROTECTED] ax | grep dove > 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot > 11447 ?? S 0:00.02 dovecot-auth > 17279 p2 RV 0:00.00 grep dove (csh) > > [EMAIL PROTECTED] attach 11447 -w process I meant just "gdb attach 11447". Except not 11447 but the "dovecot-auth -w" process. Apparently it hasn't been started yet. You could do a login with invalid user/pass to make sure it's created but without getting it to crash. But this isn't really needed since you managed to get a noncorrupted backtrace anyway using the core. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot Authentication Problem - Help pls!
* On 04/06/07 02:59 +0300, Timo Sirainen wrote: | On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote: | > Here is a backtrace of the dovecot-auth crash: | | Two problems with it: | | > #0 0x805dc00 in userdb_blocking_lookup () | | Debugging symbols were stripped. Could you try building it without | removing them, at least from dovecot-auth binary? I guess "make install" | does the stripping, so maybe copying the file manually would preserve | it. You can anyway check this with "file dovecot-auth" to see if it says | "stripped" or "not stripped". | | > (gdb) bt | > #0 0x805dc00 in userdb_blocking_lookup () | > #1 0x805dd50 in userdb_blocking_lookup () | > #2 0x806175a in sql_drivers_register_all () | > #3 0x8060d1c in sql_query () | > #4 0x805de62 in userdb_blocking_lookup () | > #5 0x8055724 in auth_stream_is_empty () | > #6 0x80557f4 in auth_stream_is_empty () | > #7 0x8055894 in auth_stream_is_empty () | > #8 0x80668ac in io_loop_handler_run () | > #9 0x80662a1 in io_loop_run () | > #10 0x805770f in main () | > #11 0x804fd52 in _start () | | Also this backtrace is corrupted for some reason. One (pretty) sure way | to get a non-corrupted backtrace is to attach gdb to dovecot-auth while | it's still running: | | gdb attach | cont | | bt full How about a ktrace of the process? This is what I have obtained: 11447 dovecot-auth 1180940592.819025 RET poll 0 11447 dovecot-auth 1180940592.819090 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940592.819100 RET gettimeofday 0 11447 dovecot-auth 1180940592.819110 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940592.819119 RET gettimeofday 0 11447 dovecot-auth 1180940592.819125 CALL poll(0x808d000,0xb,0x7d0) 11447 dovecot-auth 1180940594.831510 RET poll 0 11447 dovecot-auth 1180940594.831527 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940594.831537 RET gettimeofday 0 11447 dovecot-auth 1180940594.831547 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940594.831555 RET gettimeofday 0 11447 dovecot-auth 1180940594.831562 CALL poll(0x808d000,0xb,0x3cd) 11447 dovecot-auth 1180940595.805384 RET poll 0 11447 dovecot-auth 1180940595.805403 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940595.805412 RET gettimeofday 0 11447 dovecot-auth 1180940595.805435 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940595.805444 RET gettimeofday 0 11447 dovecot-auth 1180940595.805450 CALL poll(0x808d000,0xb,0x402) 11447 dovecot-auth 1180940596.832265 RET poll 0 11447 dovecot-auth 1180940596.832286 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940596.832295 RET gettimeofday 0 11447 dovecot-auth 1180940596.832305 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940596.832314 RET gettimeofday 0 11447 dovecot-auth 1180940596.832319 CALL poll(0x808d000,0xb,0x7d0) 11447 dovecot-auth 1180940598.833031 RET poll 0 11447 dovecot-auth 1180940598.833048 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940598.833057 RET gettimeofday 0 11447 dovecot-auth 1180940598.833067 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940598.833075 RET gettimeofday 0 11447 dovecot-auth 1180940598.833082 CALL poll(0x808d000,0xb,0x7b4) 11447 dovecot-auth 1180940600.805923 RET poll 0 11447 dovecot-auth 1180940600.805936 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940600.805945 RET gettimeofday 0 11447 dovecot-auth 1180940600.805968 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940600.805977 RET gettimeofday 0 11447 dovecot-auth 1180940600.805983 CALL poll(0x808d000,0xb,0x1c) 11447 dovecot-auth 1180940600.834805 RET poll 0 11447 dovecot-auth 1180940600.834864 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940600.834874 RET gettimeofday 0 11447 dovecot-auth 1180940600.834884 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940600.834893 RET gettimeofday 0 11447 dovecot-auth 1180940600.834900 CALL poll(0x808d000,0xb,0x7d0) 11447 dovecot-auth 1180940602.835552 RET poll 0 11447 dovecot-auth 1180940602.835568 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940602.835577 RET gettimeofday 0 11447 dovecot-auth 1180940602.835586 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940602.835595 RET gettimeofday 0 11447 dovecot-auth 1180940602.835600 CALL poll(0x808d000,0xb,0x7d0) 11447 dovecot-auth 1180940604.836309 RET poll 0 11447 dovecot-auth 1180940604.836323 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth 1180940604.836332 RET gettimeofday 0 11447 dovecot-auth 1180940604.836342 CALL gettimeofday(0xbfbff988,0) 11447 dovecot-auth 1180940604.836351 RET gettimeofday 0 11447 dovecot-auth 1180940604.836357 CALL poll(0x808d000,0xb,0x3c9) 11447 dovecot-auth 1180940605.806192 RET poll 0 11447 dovecot-auth 1180940605.806211 CALL gettimeofday(0x8080f3c,0x8080f44) 11447 dovecot-auth
Re: [Dovecot] Dovecot Authentication Problem - Help pls!
* On 04/06/07 02:59 +0300, Timo Sirainen wrote: | On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote: | > Here is a backtrace of the dovecot-auth crash: | | Two problems with it: | | > #0 0x805dc00 in userdb_blocking_lookup () | | Debugging symbols were stripped. Could you try building it without | removing them, at least from dovecot-auth binary? I guess "make install" | does the stripping, so maybe copying the file manually would preserve | it. You can anyway check this with "file dovecot-auth" to see if it says | "stripped" or "not stripped". | | > (gdb) bt | > #0 0x805dc00 in userdb_blocking_lookup () | > #1 0x805dd50 in userdb_blocking_lookup () | > #2 0x806175a in sql_drivers_register_all () | > #3 0x8060d1c in sql_query () | > #4 0x805de62 in userdb_blocking_lookup () | > #5 0x8055724 in auth_stream_is_empty () | > #6 0x80557f4 in auth_stream_is_empty () | > #7 0x8055894 in auth_stream_is_empty () | > #8 0x80668ac in io_loop_handler_run () | > #9 0x80662a1 in io_loop_run () | > #10 0x805770f in main () | > #11 0x804fd52 in _start () | | Also this backtrace is corrupted for some reason. One (pretty) sure way | to get a non-corrupted backtrace is to attach gdb to dovecot-auth while | it's still running: | | gdb attach | cont | | bt full Hi Timo, You were right. `make install` did strip it. file `locate dovecot-auth` /usr/local/libexec/dovecot/dovecot-auth: ELF 32-bit LSB executable, \ Intel 80386, version 1 (FreeBSD), for FreeBSD 4.9.2, dynamically linked \ (uses shared libs), stripped I have built and manually copied dovecot-auth to the install destination and now it id not stripped. Now this is the result of the debug: [EMAIL PROTECTED] /usr/local/libexec/dovecot/dovecot-auth /var/run/dovecot/dovecot-auth.core GNU gdb 4.18 (FreeBSD) Copyright 1998 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-unknown-freebsd"...(no debugging symbols found)... Core was generated by `dovecot-auth'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)...done. Reading symbols from /usr/local/lib/compat/pkg/libmysqlclient.so.10...(no debugging symbols found)...done. Reading symbols from /usr/lib/libm.so.2...(no debugging symbols found)...done. Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done. Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. #0 0x805d848 in sql_query_get_result () (gdb) bt #0 0x805d848 in sql_query_get_result () #1 0x805d998 in sql_query_callback () #2 0x8061396 in driver_mysql_query () #3 0x8060964 in sql_query () #4 0x805daaa in userdb_sql_lookup () #5 0x805536c in auth_worker_handle_user () #6 0x805543c in auth_worker_handle_line () #7 0x80554dc in auth_worker_input () #8 0x8065e34 in io_loop_handler_run () #9 0x8065829 in io_loop_run () #10 0x8057357 in main () #11 0x804f99a in _start () (gdb) BTW, I don't understand all that stuff:-) While trying the other method you have detailed, I just don't seem to get it right: [EMAIL PROTECTED] ax | grep dove 11446 ?? Ss 0:00.04 /usr/local/sbin/dovecot 11447 ?? S 0:00.02 dovecot-auth 17279 p2 RV 0:00.00 grep dove (csh) [EMAIL PROTECTED] attach 11447 -w process Excess command line arguments ignored. (process) GNU gdb 4.18 (FreeBSD) Copyright 1998 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-unknown-freebsd"... attach: No such file or directory. /var/run/dovecot/11447: No such file or directory. Attaching to process 11447 0x2812bc50 in ?? () (gdb) Why does it say "attach: No such file or directory"? (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) n Not confirmed. (gdb) cont Continuing. After that, I connect to either the pop3/imap and try to authenticate, upon which I get the error I have been getting, but when I tell gdb 'bt full', then nothing happens... I could be mising another point along the way, even after reading the man page of gdb on this FreeBSD box. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo
Re: [Dovecot] Dovecot Authentication Problem - Help pls!
On Sun, 2007-06-03 at 21:20 +0300, Odhiambo WASHINGTON wrote: > Here is a backtrace of the dovecot-auth crash: Two problems with it: > #0 0x805dc00 in userdb_blocking_lookup () Debugging symbols were stripped. Could you try building it without removing them, at least from dovecot-auth binary? I guess "make install" does the stripping, so maybe copying the file manually would preserve it. You can anyway check this with "file dovecot-auth" to see if it says "stripped" or "not stripped". > (gdb) bt > #0 0x805dc00 in userdb_blocking_lookup () > #1 0x805dd50 in userdb_blocking_lookup () > #2 0x806175a in sql_drivers_register_all () > #3 0x8060d1c in sql_query () > #4 0x805de62 in userdb_blocking_lookup () > #5 0x8055724 in auth_stream_is_empty () > #6 0x80557f4 in auth_stream_is_empty () > #7 0x8055894 in auth_stream_is_empty () > #8 0x80668ac in io_loop_handler_run () > #9 0x80662a1 in io_loop_run () > #10 0x805770f in main () > #11 0x804fd52 in _start () Also this backtrace is corrupted for some reason. One (pretty) sure way to get a non-corrupted backtrace is to attach gdb to dovecot-auth while it's still running: gdb attach cont bt full signature.asc Description: This is a digitally signed message part
[Dovecot] Dovecot Authentication Problem - Help pls!
Hello List,
This is dovecot 1.0.0 on FreeBSD 4.11-STABLE. I did not provide this
information before:-)
I am back again and I think I am edging closer to getting a solution.
I have done some modifications and now dovecot gives me a different
error message than before
Here is what I have for the password_query and user_query
password_query = SELECT popbox.cleartext AS password FROM popbox, domain \
WHERE popbox.local_part = 'eddie' AND popbox.domain_name = 'demo.wananchi.com' \
AND popbox.domain_name = domain.domain_name;
+--+
| password |
+--+
| boeing8 |
+--+
user_query = SELECT CONCAT(domain.path, '/', popbox.mbox_name) as home, \
69 as uid, 6 as gid FROM popbox, domain WHERE popbox.local_part = 'eddie' \
AND popbox.domain_name = 'demo.wananchi.com' AND \
popbox.domain_name = domain.domain_name;
++-+-+
| home | uid | gid |
++-+-+
| /var/spool/virtual/demo.wananchi.com/eddie | 69 | 6 |
++-+-+
When I test to connect to the pop3 daemon, this is what happens now:
[EMAIL PROTECTED] 0 7173
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
+OK Welcome. Dovecot is Ready to serve your emails.
user [EMAIL PROTECTED]
+OK
pass boeing8
-ERR [IN-USE] Internal login failure. Refer to server log for more information.
Connection closed by foreign host.
...and this is what dovecot writes to the log:
[EMAIL PROTECTED] /var/log/dovecot.log
dovecot: May 30 12:00:04 Info: auth(default): client in: AUTH 1 PLAIN
service=POP3secured lip=62.8.64.4 rip=62.8.64.4
resp=AGVkZGllQGRlbW8ud2FuYW5jaGkuY29tAGJvZWluZzg=
dovecot: May 30 12:00:04 Info: auth-worker(default): mysql: Connected to
localhost (virtualemail)
dovecot: May 30 12:00:04 Info: auth-worker(default): sql([EMAIL
PROTECTED],62.8.64.4): query: SELECT popbox.cleartext AS password FROM popbox,
domain WHERE popbox.local_part = 'eddie' AND popbox.domain_name =
'demo.wananchi.com' AND popbox.domain_name = domain.domain_name
dovecot: May 30 12:00:04 Info: auth(default): client out: OK1 [EMAIL
PROTECTED]
dovecot: May 30 12:00:04 Info: auth(default): master in: REQUEST2
36772 1
dovecot: May 30 12:00:04 Info: auth-worker(default): sql([EMAIL
PROTECTED],62.8.64.4): SELECT CONCAT(domain.path, '/', popbox.mbox_name) as
home, 69 as uid, 6 as gid FROM popbox, domain WHERE popbox.local_part =
'eddie' AND popbox.domain_name = 'demo.wananchi.com' AND popbox.domain_name =
domain.domain_name
dovecot: May 30 12:00:05 Error: child 39853 (auth-worker) killed with signal 11
dovecot: May 30 12:00:05 Info: auth(default): master out: FAIL 2
dovecot: May 30 12:00:05 Info: pop3-login: Internal login failure: user=<[EMAIL
PROTECTED]>, method=PLAIN, rip=62.8.64.4, lip=62.8.64.4, secured
User's mail is stored in /var/spool/virtual/$domain/$user/{new,cur,tmp}
The path /var/spool/virtual/ is owned by uid:gid 69:6, and is writeable
by that uid.
dovecot -n:
# /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
protocols: imap pop3
listen(default): *:7143
listen(imap): *:7143
listen(pop3): *:7110
ssl_disable: yes
disable_plaintext_auth: no
shutdown_clients: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: exim
login_greeting: Welcome. Dovecot is Ready to serve your emails.
login_process_size: 64
login_max_processes_count: 200
verbose_proctitle: yes
first_valid_uid: 69
first_valid_gid: 0
mail_extra_groups: dovecot:mail
mail_location: maildir:/var/spool/virtual/%d/%n
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail outlook-idle netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3): outlook-idle
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
mechanisms: plain login digest-md5 cram-md5
verbose: yes
debug_passwords: yes
passdb:
driver: sql
args: /usr/local/etc/dovecot-sql.conf
userdb:
driver: sql
args: /usr/local/etc/dovecot-sql.conf
socket:
type: listen
client:
path: /var/run/dovecot/auth-client
mode: 432
master:
path: /var/run/dovec
