dovecot - Nov 2007 - dovecot-auth consumes 100% CPU time on Solaris 10

Is problem with CPU load solved?

I have same problem - dovecot-auth eats one of my cores.
I'm using dovecot 1.0.7 on Solaris 10 Sparc.
I tried to use auth-bind and standard scheme with separate user for bind and
have same result.
Problem occupts only with LDAP authentication, on some other systems I use
PostgreQSL and MySQL authentication and doesn't have this problem.
Using PAM authentication is not possible, because dovecot run in chroot'ed
environment and I planing to move it to separate system or zone without ldap
client.

-- 
MATPOCKuH

I tried to make dovecot with configure --with-ioloop=select and same result:
[skipped]
pollsys(0xFFBFF888, 8, 0xFFBFF950, 0x00000000)  = 1
pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000)  = 0
pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000)  = 0
pollsys(0xFFBFF888, 8, 0xFFBFF950, 0x00000000)  = 1
pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000)  = 0
pollsys(0xFFBFF4D8, 5, 0xFFBFF458, 0x00000000)  = 0
[skipped to forever]
and 100% of CPU time.

May be problem is in select() (poll() ?) call with unnecessary file
descriptor, who always ready (may be connection to LDAP server?) ?

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. *