[Samba] NEG_CONN_CACHE questions

[Jeremy Allison]

On Thu, May 28, 2020 at 01:11:26PM -0700, Alexey A Nikitin wrote:
> On Wednesday, 27 May 2020 16:21:31 PDT Jeremy Allison wrote:
> > On Wed, May 27, 2020 at 12:54:49PM -0700, Alexey A Nikitin via samba wrote:
> > > 3. Are the rules for how a DC gets put into NEG_CONN_CACHE documented anywhere besides the code itself, or wading through the code is my only option of getting to know the criteria?
> > 
> > Only in the code I think, added in:
> > 
> > add_failed_connection_entry()
> > 
> > Can be cleared by:
> > 
> > flush_negative_conn_cache_for_domain(), which is triggered
> > by winbindd getting a request to go online.
> > 
> 
> But if winbind is configured with 'winbind offline logon = No'
> then, from what I understand, winbindd will never get that request, except for maybe on restart, no?

Yes, but the TTL is set at 60 seconds, so it should
be removed 60 seconds after being added anyway.

> Related question - it seems that when I have 'winbind max domain connections' set to a
> value above '1' Winbind attempts to open a new connection for incoming authentication
> requests, judging from the fact that it keeps trying to do DC location (but fails,
> because both candidate DCs are stuck in NEG_CONN_CACHE for some reason, even if they're
> answering request from, e.g., adcli).

You should try to find out the request that caused them to
get put into the NEG_CONN_CACHE. In winbindd, look at the
calls to winbind_add_failed_connection_entry() - there are
several reasons that this might get called.

> There is already an RPC pipe (ESTAB connection to port 49159 on DC), but
> Winbind seems to insist on opening a new connection and doesn't reuse existing.
> Am I misinterpreting something? I thought Winbind is supposed to open a new connection only when existing one is busy with some request?

'winbind max domain connections' causes the
parent winbindd to chose the winbindd child
with the shortest queue to talk to.

Then it sends an async tevent_req request
to that child. I don't think it's opening
a new connection to the DC.

Add DBG_ERR() (log level 0) statements into the places
you are suspicious of and try and follow the
control flow.