Hostnames fail to resolve

[ire4ever1190]

All hostnames fail to resolve inside the container. I have verified it has connection since I can run curl 1.1.1.1 but trying httpbin.org/ip fails. dnsmasq starts but seems to be stuck since it just eats all of my CPU

This was the command used to start the container using docker v24.0.7

docker run -it --rm termux/termux-docker:x86_64

[THEGOLDENPRO]

yeah, same issue here. I can't pkg update and I'm not running with --user.

~ $ pkg update
No mirror or mirror group selected. You might want to select one by running 'termux-change-repo'
Testing the available mirrors:
[*] (10) https://packages-cf.termux.dev/apt/termux-main: bad
[*] (1) https://tmx.xvx.my.id/apt/termux-main: bad
[*] (1) https://mirror.textcord.xyz/termux/termux-main: bad
[*] (1) https://mirror.nevacloud.com/applications/termux/termux-main: bad
[*] (1) https://linux.domainesia.com/applications/termux/termux-main: bad
[*] (1) https://mirrors.cbrx.io/apt/termux/termux-main: bad
[*] (1) https://mirror.albony.xyz/termux/termux-main: bad
[*] (1) https://mirror.bardia.tech/termux/termux-main: bad
[*] (1) https://mirror.iscas.ac.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.sdu.edu.cn/termux/termux-main: bad
[*] (1) https://mirrors.qvq.net.cn/termux/termux-main: bad
[*] (1) https://mirrors.sustech.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.hit.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.bfsu.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.scau.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirror.sjtu.edu.cn/termux/termux-main/: bad
[*] (1) https://mirrors.zju.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.nju.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.ustc.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.dgut.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.pku.edu.cn/termux/termux-main/: bad
[*] (1) https://mirror.nyist.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.sau.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.tuna.tsinghua.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.njupt.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirrors.aliyun.com/termux/termux-main: bad
[*] (1) https://mirrors.cqupt.edu.cn/termux/apt/termux-main: bad
[*] (1) https://mirror.sunred.org/termux/termux-main: bad
[*] (1) https://termux.3san.dev/termux/termux-main: bad
[*] (4) https://grimler.se/termux/termux-main: bad
[*] (1) https://mirror.accum.se/mirror/termux.dev/termux-main: bad
[*] (1) https://termux.astra.in.ua/apt/termux-main: bad
[*] (1) https://mirror.autkin.net/termux/termux-main: bad
[*] (1) https://mirrors.cfe.re/termux/termux-main: bad
[*] (1) https://mirror.bouwhuis.network/termux/termux-main: bad
[*] (1) https://termux.librehat.com/apt/termux-main: bad
[*] (1) https://mirror.mwt.me/termux/main: bad
[*] (1) https://mirror.termux.dev/termux-main: bad
[*] (1) https://ro.mirror.flokinet.net/termux/termux-main: bad
[*] (1) https://mirrors.sahilister.in/termux/termux-main: bad
[*] (1) https://is.mirror.flokinet.net/termux/termux-main: bad
[*] (1) https://ftp.fau.de/termux/termux-main: bad
[*] (1) https://termux.cdn.lumito.net/termux-main: bad
[*] (1) https://termux.mentality.rip/termux-main: bad
[*] (1) https://packages.termux.dev/apt/termux-main: bad
[*] (1) https://mirrors.medzik.dev/termux/termux-main: bad
[*] (1) https://md.mirrors.hacktegic.com/termux/termux-main: bad
[*] (1) https://mirror.quantum5.ca/termux/termux-main: bad
[*] (1) https://mirror.mwt.me/termux/main: bad
[*] (1) https://mirror.fcix.net/termux/termux-main: bad
[*] (1) https://dl.kcubeterm.com/termux-main: bad
[*] (1) https://plug-mirror.rcac.purdue.edu/termux/termux-main: bad
[*] (1) https://mirror.csclub.uwaterloo.ca/termux/termux-main: bad
[*] (1) https://mirrors.utermux.dev/termux/termux-main: bad
[*] (1) https://mirror.vern.cc/termux/termux-main: bad
[*] (1) https://mirror.endianness.com/termux/termux-main: bad
[*] (1) https://mirrors.rda.run/termux/termux-main: bad
[*] (1) http://mirror.mephi.ru/termux/termux-main: bad
[*] (1) https://repository.su/termux/termux-main/: bad
Error: None of the mirrors are accessible

[truboxl]

I can't reproduce it on Docker Desktop Windows v25.0.3 using WSL2. Are you using something other host OS?

[ire4ever1190]

Host OS is arch Linux

[THEGOLDENPRO]

I'm also on Arch Linux. Maybe our issue is related to #55

[postmodern]

Also just ran into this on Fedora Linux using a fresh pull of termux/termux-docker:latest. Oddly enough, ping is able to resolve host names, but curl or apt cannot.

$ docker run -it --rm termux/termux-docker:latest
~ $ apt update
Ign:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease
Ign:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease
Ign:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease
Err:1 https://packages-cf.termux.dev/apt/termux-main stable InRelease
  Something wicked happened resolving 'packages-cf.termux.dev:https' (7 - No address associated with hostname)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.
W: Failed to fetch https://packages-cf.termux.dev/apt/termux-main/dists/stable/InRelease  Something wicked happened resolving 'packages-cf.termux.dev:https' (7 - No address associated with hostname)
W: Some index files failed to download. They have been ignored, or old ones used instead.
~ $ ping packages-cf.termux.dev
PING packages-cf.termux.dev (172.67.200.228): 56 data bytes
ping: permission denied (are you root?)
~ $ curl https://packages-cf.termux.dev
curl: (6) Could not resolve host: packages-cf.termux.dev

[you-oops-dev]

I “solved” the problem. By rolling back the commit 15a788b . By building a docker image.

sudo ./build-all.sh

Run it like this:

sudo docker run --restart=always -e TERM="xterm" -it IMAGE_ID

The most important thing I forgot to write resolving domains works. At least so than nothing.

Temporary solution to who needs a very termux in the docker.

[THEGOLDENPRO]

I “solved” the problem. By rolling back the commit 15a788b . By building a docker image.

Thanks 💙 I'll try that out the next time I need this again.

[2-4601]

TL;DR

The root cause is how dnsmasq behaves with too lax limits for open files. You can mitigate this issue by explicitly restricting the number of open file descriptors for the container. For example:

$ docker run --rm --tty --interactive --ulimit nofile=1048576:1048576 termux/termux-docker:latest

Longer explanation

I also run into this issue on Arch Linux with Docker v26.1.4. The dnsmasq process (/system/bin/dnsmasq -u root -g root --pid-file /dnsmasq.pid) ate all resources of a single CPU core and networking did not work.

Next I tested with Ubuntu 24.04 both with the Canonical packaged Docker v24.0.7 and the latest community edition of Docker v26.1.4. Everything worked fine on Ubuntu on both Docker versions.

Because the same Docker version produced different behaviour in Arch and Ubuntu, something in Arch must have been different.

strace showed that dnsmasq was calling fstat64 ad nauseam and those calls ended in EBADF (Bad file descriptor) errors.

Then I tried gdb from the host OS to see what the process is doing. Not very reliable but at least I got something out of it, namely the function name:

#0  0xe9f08579 in __kernel_vsyscall ()
#1  0xe9d29938 in fstat64 () from target:/system/lib/libc.so
#2  0x6102c5f3 in closeUnwantedFileDescriptors ()
#3  0x6102c738 in main ()

Turns out closeUnwantedFileDescriptors is part of the Android fork of dnsmasq. First introduced in this commit, but the method is still the same in the current version. It goes through all the possible file descriptors (limited by the maximum for processes) and closes all but the stdout, stderr and stdin. Now imagine if the maximum number of open files is large, such as 2^30. It's going to take a while to try to close all those non-existant file descriptors. In the upstream dnsmasq, this was optimised to use /proc, but the Android version of dnsmasq is still using the traditional brute force approach.

In Arch, you can see the current limit in the Termux Docker container with:

termux-docker@arch$ ulimit -n
1073741816

And if you run the same when the host OS is Ubuntu:

termux-docker@ubuntu$ ulimit -n
1048576

So by default, Arch is using a much larger limit for open file descriptors. And that's why dnsmasq hangs because it tries to close all of them.

These limits originate most likely from the default kernel parameters:

arch$ sysctl fs.nr_open
fs.nr_open = 1073741816

ubuntu$ sysctl fs.nr_open
fs.nr_open = 1048576

If you don't want to change the kernel parameters, you can just restrict them for the termux-docker container. For example, to use the default limits of Ubuntu's kernel:

$ docker run --rm --tty --interactive --ulimit nofile=1048576:1048576 termux/termux-docker:latest

Now the container's dnsmasq does not hang any more in Arch Linux.

---

Fix

A possible fix could be adding something modest, such as ulimit -n 4096, before starting the dnsmasq process in the entry point scripts. I quickly tested that and it works.

[robertkirkman]

@2-4601 I have created a PR #72 that implements many changes to the internal components of termux-docker.

One of the changes is that the dnsmasq implementation is replaced with this one, which contains the "optimized" code you linked.

If you want to, could you test my implementation and let me know whether it completely fixes this issue or not?

Edit: I have now reproduced this issue with the current official termux-docker on one of my x86_64 devices, including verifying that the dnsmasq process used 100% of a CPU core, and then immediately afterward I tested my PR version of termux-docker on the same device, and could not reproduce the issue with it, so at least on my device I can confirm my PR also fixes this issue.

[2-4601]

If you want to, could you test my implementation and let me know whether it completely fixes this issue or not?

Just tested your PR, and the issue is fixed.