Thanks Robbie for the inputs.. the load should not have been high as I have
around 4000 clients with 160 users which should be manageable
However, I saw a lot of clock skew too great errors in my krb5kdc.log...
however I haven't been able to verify if those were genuine...
Can too many clock skew errors take down the kerberos service..
On Mon, Sep 19, 2016 at 10:15 PM, Robbie Harwood <rharw...@redhat.com>
> Rakesh Rajasekharan <rakesh.rajasekha...@gmail.com> writes:
> > On Mon, Sep 12, 2016 at 10:13 AM, Rakesh Rajasekharan
> > <rakesh.rajasekha...@gmail.com <mailto:rakesh.rajasekha...@gmail.com>>
> > wrote:
> > sorry I guess I did not put the question correctly....
> > I wanted to know .. like we have the ListenBacklog for apache to
> > basically define the number of connections it can handle.. do we
> > have some thing similar for our krb5kdc service.. as the SYN floodin
> > at 88 looks like krb5kdc service is not able to handle sudden spurt
> > in connections or the number of connections are more than it could
> > handle..
> > So, would be great if I could know how many connection it can
> > support at any given time ..most of the times I see this error while
> > i add clients to IPA master.. so if thers a known limit , I could
> > first check netstat to see how many connections I have at any point
> > and if its below the limit only then setup ipa-client-install
> We intentionally do not have such a parameter in krb5. We call
> listen(5) internally, but please note this is probably not the parameter
> you want to be able to tune.
> The listen() backlog is the number of connections that are waiting to be
> accept()ed by the process. They sit in the kernel, not receiving
> SYNACK. This number does not count connections that the process - here
> krb5kdc - has accept()ed and is currently processing.
> If you're truly seeing connections faster than they can be accept()ed,
> you have a load problem that tuning this parameter likely won't fix.
> You should probably configure replicas: krb5 will fall back if the
> connection is refused from one kdc to the next configured one. This
> will result in faster operation for your users than waiting on an
> enormous listen() backlog will as well.
> A tunable for the listen value may be added in the future, but is not
> available at the present time.
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project