A winbindd architecture question for the winbindd gurus out there...

Tim Prouty tim.prouty at isilon.com
Sat Jan 12 01:30:21 GMT 2008

I have question about how the req/recv messaging works between child/ 
parent processes in winbindd. It is currently my understanding that  
the EVENT_FD_WRITE flag is set when a message is scheduled to be sent  
to the child (by writing the child's write socket).  The flag is set  
until the data is actually written to the socket, so if another  
request comes in that needs to be written to the socket, it is added  
to the child's list of requests (child->requests).  In this case, I'm  
not seeing the request being written to the socket, but instead the  
queue keeps growing until winbindd cores due to this memory leak.  Is  
there some mechanism that should be allowing the queue to be flushed?

Above the event code in winbindd.c there is the following comment:

  * This is the main event loop of winbind requests. It goes through a
  * state-machine of 3 read/write requests, 4 if you have extra data  
to send.

This leads me to believe that state 4 is the state that winbindd  
should be getting into when it receives that second request.  I  
haven't found any code that handles this 4th state.  Am I missing  

While I am seeing this behavior on 3.0.24 (plus a bunch of cherry  
picked and custom patches), the code in 3.2.stable doesn't seem to  
handle this any differently.  My question is first about understanding  
the design of winbindd's messaging, and from there fixing the memory  

In case your curious, I'm seeing this in a fairly complex domain  
topology with many different types of trusts (transitive, one-way,  
parent/child).  The winbindd message queue grows during the trust  
enumeration code that Jerry Carter added at the bottom of  
trustdom_recv, while also hammering winbindd with:

while (true); do wbinfo --all-domains &> /dev/null; done

Jeremy, I have not run valgrind yet, but with dmalloc I was able to  
determine that I'm leaking thousands of "add_trusted_domains" talloc  


Tim Prouty | Software Development Engineer
Isilon Systems    P +1-206-315-7500     F  +1-206-315-7485
www.isilon.com    D +1-206-315-7494    M +1-206-963-5747

More information about the samba-technical mailing list