Re: Linux jail 14-CURRENT: DNS does not work for *some* programs?
Date: Tue, 10 Jan 2023 07:40:13 UTC
Quoting Mathias Picker <Mathias.Picker@virtual-earth.de> (from Tue, 10 Jan 2023 06:51:06 +0100): > Hi all, > > I’m testing a few linux triplestore in a linux jail, and used 13.1 > which worked fine most of the time. > > Now one of the stores shows dropped connections with many clients, > and as I can see logs of netlink errors in the logs, I thought I’d > try -CURRENT. > > Sadly, my linux jail (Ubuntu 16.04.7) now shows an irritating > behaviour, some programs seem to hang indefinitely waiting for name > resolution: > > Inside the jail: > > Working version with ping [example] > Non-working with wget (same for curl and others) [example] > So, this tcpdump looks pretty much as if both got answers from unbound. > Why is wget (and host, and curl, and sudo) not “getting” this answer? > > Any ideas where to look or questions about my setup welcome! Current has netlink support, 13.1 doesn't. Current may have changes in the linuxumaltor, which aren't in 13.1. You need to debug the kernel path. Possible tools to do so are ktrace and dtrace. The most easy cmdline would be ktrace, whereas dtrace gives more flexibility in what you do and how you look at it. As a first step I would recommend ktrace. Not sure if it will work as I want it to work... ktrace -di jexec "ID or name of jail" ping google.de After you have seen the answer with tcpdump, you can kill ktrace/ping (or wait for a timeout, but this will increase the amount of data traced) and inspect the result via "kdump" (this will take the file "ktrace.out" in the current directory and print out the data). IF this works (I'm not sure if the ktrace inherits(descents into a jail), you will see the calls to jexec and the exec of ping and what all those do in the kernel. This will then give a hint where to look next. IF this doesn't work, you can use "ktrace -di -p <pid of ping>" from the jail-host while ping is running. If ping tries to redo the DNS lookup, or a second nameserver is configured and it tries to get the info from the second after a timeout, you may be lucky to catch that in the trace. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF