Winbindd using 100% of CPU. Any solution?
realrichardsharpe at gmail.com
Mon Jan 6 08:12:21 MST 2014
On Mon, Jan 6, 2014 at 2:12 AM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Sat, Jan 04, 2014 at 11:04:41AM -0800, Richard Sharpe wrote:
>> So many red herrings.
>> Here is the problem in my case.
>> For some reason, in this customer's case, they have a domain called
>> EXCHANGE and one called XCHANGE, but both seem to have the same DNS
>> name (xchange.some.dom). One of them seems permanently offline as
>> well, but that does not matter here.
>> When we get the list of trusted domains, some times, we already have
>> one of them, EXCHANGE, and we receive an entry for XCHANGE (I think it
>> happens in that order.) We search for the domain in
>> rescan_forest_trusts, but the search routine doesn't find it. However,
>> add_trusted_domain does find the existing one because it also compares
>> the alt_name (dns_name passed in) and returns the other entry. We then
>> call setup_domain_child on that domain, which calls setup_child.
>> In setup_child we do:
>> child->sock = -1;
>> child->domain = domain;
>> which then causes us to call fork_domain_child in
>> wb_child_request_trigger and bang, we insert the same entry again and
>> corrupt the list.
> "the list" -- you mean we corrupt the _domain_list variable?
> I can believe that we add invalid entries with weird names,
> but I failed to see yet how we can corrupt the doubly linked
> list itself. We only call DLIST_ADD on a freshly malloced
> structure. Am I missing something?
Because that weird pair of domains with the same DNS address probably
violates one of our assumptions, setup_domain_child can return with an
existing entry that looks like it has been freshly TALLOC'd and we
I have managed to re-contact the initial reporter of this problem and
am trying to track down how they managed to get such an AD config so
we can repro it.
More information about the samba-technical