Problem with traceroute - Buster stock / Stretch kernels 4.19 / 5.0
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
Re: problem with traceroute
Scott Barker [EMAIL PROTECTED] writes: Interesting. I've had no problems at all with BIND... If you're running a 1.2.x kernel and an unstable bind, zone transfers from your machine will fail (because it attempts to get the ip options, something not supported in 1.2.x, and on failure drops the connection.) This only matters if you're the primary DNS for some domain (which my 1.2.13 machine is.)
Re: problem with traceroute
Scott Barker [EMAIL PROTECTED] writes: traceroute: IP_HDRINCL: Protocol not available I've also noticed this under 1.2.13. (the same package works fine on my 1.3.79 machine, and I should really update both kernels...) There are actually a number of unstable packages that don't work under 1.2.13 -- most have explicit dependencies (diald used to, for example) but some don't. BIND, for example, needs the ip_options support that was added in 1.3 (though I've submitted a reasonably clean fix for that, I understand if there isn't much interest in it.) Certainly once 2.0 comes out I'll give up and upgrade :-)
Re: problem with traceroute
Mark Eichin said: There are actually a number of unstable packages that don't work under 1.2.13 -- most have explicit dependencies (diald used to, for example) but some don't. BIND, for example, needs the ip_options support that was added in 1.3 (though I've submitted a reasonably clean fix for that, I understand if there isn't much interest in it.) Interesting. I've had no problems at all with BIND... Guess I may have to bite the bullet and use a development kernel if 2.x doesn't come out real soon... -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 5 days. If you don't ] [ get a response by then, I probably didn't get your e-mail ] [ (we have a sometimes sporadic connection to the internet) ] What we call 'Progress' is the exchange of one nuisance for another nuisance. - Henry Havelock Ellis
problem with traceroute
Since upgrading netstd to version 2.03-1, I'm getting the following error out of traceroute: traceroute: IP_HDRINCL: Protocol not available Is this because I'm still running a 1.2.13 kernel? Is the above protocol something new in 1.3.xx? -- Scott Barker Linux Consultant [EMAIL PROTECTED] http://www.cuug.ab.ca:8001/~barkers/ (under construction) [ I try to reply to all e-mail within 5 days. If you don't ] [ get a response by then, I probably didn't get your e-mail ] [ (we have a sometimes sporadic connection to the internet) ] It takes a long time to understand nothing. - Edward Dahlberg
