On 8/18/24 18:08, bblinux wrote:
ished ...>
[pid 79822] prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1073741816,
rlim_max=1073741816}) = 0
[pid 79822] close(3) = 0
[pid 79822] close(4) = 0
[pid 79822] close(45493) = -1 EBADF (Bad file descriptor)
... forever
This is the key.
qemu closes all possible file descriptors.
It always did that, for still unknown to me reason.
In your case, the system is configured to have 1073741816
possible open files. This is not the default (the default
is 1024). I dunno where such huge limit comes from and why
it is set up this way (low limit on open files is here for
a good reason).
There's a system call to close whole file range, which is used
as a better alternative, but for some reason this build of qemu
missed it, and resorted to traditional loop by every FD in
turn.
Please find out why you've so huge FD limit and why it depends
on the kernel.
I still can't reproduce this issue in a default debian install -
because I don't have such huge FD limit. However if I set it
manually, sure thing this issue becomes reproducible.
There are 3 ways to attack this issue, all 3 can be used together.
1. find out why you've such a huge limit and fix that.
2. I'll take a look why qemu does not use better close-everything
way
3. convince upstream qemu to stop doing this nonsence in the first
place. I tried this approach before, but it weren't convincing
enough.
/mjt
