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

[Jeremy Allison]

On Fri, Jan 11, 2008 at 05:30:21PM -0800, Tim Prouty wrote:
> 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  
> something?

I think so.

Look at the function : async_reply_recv() in winbindd/winbindd_dual.c.

This is the final function called once the child winbindd has
received the response from the child. Once that has retrieved
any extra data in cache_retrieve_response(), it removes the
current request from the list (DLIST_REMOVE(child->requests, state))
and then calls schedule_async_request() which writes the next operation to
the child.

schedule_async_request() is also called when the child is noticied
to have died (in winbind_child_died()).

Set a gdb breakpoint at async_reply_recv to see the next request
getting written to the child via the schedule_async_request() call.

Jeremy.