A winbindd architecture question for the winbindd gurus out
jra at samba.org
Sat Jan 12 01:49:37 GMT 2008
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
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
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.
More information about the samba-technical