Re: [Dovecot] squat plugin
Thanks Timo,
I just tried 1.1 beta 9 with fts_lucene plugin, imap seg. fault whenever a
fatch command is issued. Here is the strace for your reference:
read(0, "a uid fetch 1:* (uid)\r\n", 4080) = 23
mkdir("/home/joewong/Maildir/lucene-indexes/locks", 0700) = -1 EEXIST
(File exists)
time(NULL) = 1196327378
open("/home/joewong/Maildir/lucene-indexes",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9
fstat64(9, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(9, F_SETFD, FD_CLOEXEC) = 0
getdents64(9, /* 3 entries */, 4096)= 80
getdents64(9, /* 0 entries */, 4096)= 0
close(9)= 0
open("/home/joewong/Maildir/lucene-indexes/locks",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 9
fstat64(9, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(9, F_SETFD, FD_CLOEXEC) = 0
getdents64(9, /* 2 entries */, 4096)= 48
getdents64(9, /* 0 entries */, 4096)= 0
close(9)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 30713 detached
- Joe
On Mon, 26 Nov 2007, Timo Sirainen wrote:
> On Wed, 2007-11-21 at 00:46 +0800, Joe Wong wrote:
> > I have installed 1.1 beta 8 with fts-squat enabled. I have added the
> > plugin section in dovecot.conf. How can I actually make use of the
> > full text index?
>
> Just use SEARCH TEXT or SEARCH BODY command and Dovecot indexes the
> mailbox and then uses the indexes later automatically. i.e. do nothing
> special. :)
>
>
--
[Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
Timo, you are so right! Today in the morning I checked the libs from the dovecot-auth binary and see the following output # ldd /usr/local/libexec/dovecot/dovecot-auth libcrypt_d.so.1 => /usr/lib/libcrypt_d.so.1 libpam.so.1 => /usr/lib/libpam.so.1 libldap.so.5 => /usr/lib/libldap.so.5 ... The binary was linked with the Solaris ldap-library, not with the openldap-library. In a first test I move the Solaris library and after a rebuild everything is fine, the dovecot-auth gets 0.0% cpu time and ldd shows me the right openldap lib. After a copyback of the Solaris lib and a dovecot recompile, the process gets again 100% cpu. In my $LD_LIBRARY_PATH /usr/lib is behind /usr/local/lib (for openldap), although dovecot-auth was linked with the Solaris lib. The way that works for me is the following LDFLAGS directive to the configure command, because the --with-ldap flag has no directory option: LDFLAGS=-L"/usr/local/BerkeleyDB/lib -L/usr/local/lib /usr/local/lib/libldap-2.4.so.2" Is there a smarter way to link with the right lib and ignore the solaris one? Mark
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
hello Mark, Mark Heitmann wrote: In my $LD_LIBRARY_PATH /usr/lib is behind /usr/local/lib (for openldap), although dovecot-auth was linked with the Solaris lib. The way that works for me is the following LDFLAGS directive to the configure command, because the --with-ldap flag has no directory option: LDFLAGS=-L"/usr/local/BerkeleyDB/lib -L/usr/local/lib /usr/local/lib/libldap-2.4.so.2" Is there a smarter way to link with the right lib and ignore the solaris one? Firstly, on Solaris *NEVER* have LD_LIBRARY_PATH or LD_RUN_PATH set when compiling, it's just a whole world of pain that you don't need. Basically, the Solaris linker will forget where the libraries you linked to were if you have either of these environment variables set at link time. The runtime linker will only have its own list to fall back upon, which will be /usr/lib. Here's how to work around it:- In the LDFLAGS use: LDFLAGS="-L/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB/lib -L/usr/local/lib -R/usr/local/lib" Now, assuming that LD_LIBRARY_PATH is not defined, the linker will store in the resulting binary the correct search path for libraries in the correct order. Steve -- --- Computer Systems Administrator,E-Mail:[EMAIL PROTECTED] Department of Earth Sciences, Tel:- +44 (0)1865 282110 University of Oxford, Parks Road, Oxford, UK. Fax:- +44 (0)1865 272072
Re: [Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
Greetings - On 29 Nov 2007, at 09:24, Mark Heitmann wrote: In my $LD_LIBRARY_PATH /usr/lib is behind /usr/local/lib (for openldap), although dovecot-auth was linked with the Solaris lib. The way that works for me is the following LDFLAGS directive to the configure command, because the -- with-ldap flag has no directory option: LDFLAGS=-L"/usr/local/BerkeleyDB/lib -L/usr/local/lib /usr/local/lib/ libldap-2.4.so.2" Is there a smarter way to link with the right lib and ignore the solaris one? We used to have terrible problems similar to yours when trying to use LD_LIBRARY_PATH. We now tend to use the "-R" option as well when compiling to specify unusual/specific library directories... I think I have the following right: * "-l libraryname" searches in an ordered list of locations for a library named "libraryname". * "-L dirname" augments the above ordered list of locations with the directory "dirname". If the library is a non-shared one then the above should suffice: the library routines needed by your program are hauled into the resulting executable and stored there. However if, as is often the case, the libraries are instead shared (ie, have a ".so" suffix) then their code is NOT hauled into the executable, but is instead pulled in when the executable is actually run. The run-time link-loader does this job. The run-time link-loader also searches an ordered list of directories, this time looking for the shared libraries. However this list is NOT affected by the "-L" option you used when compiling. Instead the LD_LIBRARY_PATH (and, I think, the LD_RUN_PATH) environment variable influences this list. However it is easy to end up with an inappropriate ordering, and so use the wrong shared library when running your program. Using the "-R dirname" option at compile time "hardcodes" the named directory into your executable. When it is run this directory is also searched for searched libraries, without the need to fiddle on setting environment variables up. Typically you would list the same directories for both -L and -R options when you are using "unusual" places. Eg, cc -o executable prog.c -lsomelib -L /usr/local/BerkeleyDB/lib -R / usr/local/BerkeleyDB/lib (All on one line, of course; the mailer will probably wrap the above.) It works for us... :-) Cheers, Mike B-) -- The Computing Service, University of York, Heslington, York Yo10 5DD, UK Tel:+44-1904-433811 FAX:+44-1904-433740 * Unsolicited commercial e-mail is NOT welcome at this e-mail address. *
[Dovecot] dovecot-auth consumes 100% CPU time on Solaris 10
Here's how to work around it:- In the LDFLAGS use: LDFLAGS="-L/usr/local/BerkeleyDB/lib -R/usr/local/BerkeleyDB/lib -L/usr/local/lib -R/usr/local/lib" This works now very well, I'll keep this information in mind ... Thanks a lot @all Mark
Re: [Dovecot] SIGSEGV login process
On Wed, 28 Nov 2007 10:50:01 +0300, Maxim Lougovsky <[EMAIL PROTECTED]> wrote: > > > > On Wed, 28 Nov 2007 09:45:45 +0200, Timo Sirainen <[EMAIL PROTECTED]> wrote: >> On Thu, 2007-11-22 at 21:16 +0300, Maxim wrote: >>> #0 0x08051e2d in auth_client_request_continue () >>> (gdb) bt >>> #0 0x08051e2d in auth_client_request_continue () >>> #1 0x0804b8db in client_auth_input () >> >> Actually does this patch fix it? >> http://hg.dovecot.org/dovecot-1.0/raw-rev/73a3a6b1af36 > > sorry, am still unable reproduce it. but trying :) got it: mail# gdb /usr/local/libexec/dovecot/imap-login /var/run/dovecot/login/tmp/imap-login.core GNU gdb 6.1.1 [FreeBSD] 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-marcel-freebsd"... Core was generated by `imap-login'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libssl.so.4...done. Loaded symbols for /usr/lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x08054096 in auth_client_request_continue (request=0x0, data_base64=0x808806b "ns1 NAMESPACE") at auth-server-request.c:377 377 auth-server-request.c: No such file or directory. in auth-server-request.c (gdb) bt #0 0x08054096 in auth_client_request_continue (request=0x0, data_base64=0x808806b "ns1 NAMESPACE") at auth-server-request.c:377 #1 0x0804beef in client_auth_input (context=0x8074a00) at client-authenticate.c:72 #2 0x08059afe in io_loop_handler_run (ioloop=0x807d1c0) at ioloop-kqueue.c:153 #3 0x08058f0e in io_loop_run (ioloop=0x807d1c0) at ioloop.c:329 #4 0x0804e905 in main (argc=1, argv=0xbfbfec2c, envp=0xbfbfec34) at main.c:432
