Endless looping around socket *:88 in krb5kdc with result -1 EAGAIN (Resource temporarily unavailable)

[Greg Hudson]

On 5/5/19 7:46 AM, Дилян Палаузов wrote:
> The documentation of krb5kdc states:
> 
>    The -n option specifies that the KDC does not put itself in the background and does not disassociate itself from the
> terminal.  In normal operation, you should always allow the KDC to place itself in the background.
> 
> What is the problem of having the process running in the foreground?

There's no problem if you're running under systemd.  The documentation
was written (many years ago) assuming krb5kdc would be started from a
shell or init.d script, and you wouldn't want the shell process to
block.  I will update it.

> epoll_wait(4, [{EPOLLIN, {u32=11, u64=11}}], 32, -1) = 1
> getsockname(11, {sa_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("0.0.0.0")}, [128->16]) = 0
> recvmsg(11, {msg_namelen=128}, 0)       = -1 EAGAIN (Resource temporarily unavailable)
[repeats]
> The same happens also to 30317.  So all the krb5kdc processes are trying to bind to :88, but they cannot, as they posses
> already the port.

There's no bind() call in the repeating system calls; the loop here is
trying to read a packet from UDP listener, after being told by poll()
that the socket is readable.

Because there are multiple worker processes in this setup, this sequence
is expected to happen some of the time.  When a packet arrives, all of
the krb5kdc processes waiting in poll() are alerted that the socket is
readable.  One of them successfully reads the packet, while the others
get EAGAIN and go back into poll().

If all of the workers are doing this in a tight loop and none of them
are doing anything else, that's unexpected.  I don't know how that state
would arise.

> Restarting has helped.  What shall I do the next time this happens, so that the cause is resolved?

You could strace all of the worker processes simultaneously, with
timestamps (strace -t), to confirm what is going on.  I'm still not sure
I would be able to identify the cause, though.  This is the first report
of this problem that I can recall.