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

[Tim Prouty]

That makes sense.  Thanks Jeremy!

-Tim

On Jan 11, 2008, at 5:49 PM, Jeremy Allison wrote:

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

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