Hi,
I've already reported part of this to glibc mailing list since I was
suspecting its incompatibility with newer kernel.
https://lists.debian.org/debian-glibc/2019/03/msg00029.html My daemons
started to stuck with kernel 4.19 / 5.0. Today I discovered there is
always process of traceroute, which is consuming 100% CPU when it
happens. I'm doing a lot of tracerouting so there is one spawned most
of the time. When I strace it I got two lines over and over again.
recvmsg(3, {msg_namelen=28}, MSG_ERRQUEUE) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLERR}], 1, 0) = 1 ([{fd=3,
revents=POLLIN|POLLERR}])
My daemons can't read its output, they are blocked at read deep inside
glibc. This was also happening on Stretch when I updated to kernel
4.19 / 5.0. I need bleeding edge kernel since I'm implementing
nftables into my program and there were some patches for bugs I found,
but they were applicable to kernel 5.0 only. I haven't try it with
kernels between 4.9 - stock Stretch and 4.19 - stock Buster. I was
running about 30 servers with Stretch and my programs with patched
kernel 4.9 for months without problems. It started to happen with new
kernel. Now I'm on stock Buster and it is happening too. Problem is I
can't predict when it blocks. Sometimes minutes, sometimes hours. I
was trying to create some kind of smaller program to reproduce this
behavior but so far I had no luck to catch it inside it.
I would appreciate any help because it prevents me from finishing
implementation of nftables and updating all the servers.
----
S pozdravem / Best Regards
Vaclav Zindulka
