On Monday, August 19 2024, Michael Tokarev wrote:
> 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.
Although this is a different issue, it reminds me of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075871, which is a
bug I investigated a while ago and which displayed the same underlying
symptoms (gpg was taking forever to run inside a Debian chroot). The
problem was that /proc wasn't mounted, which prevented gpg from
optimizing the closure of file descriptors and made it fallback to a
dumb algorithm which would iterate over the hundreds of thousands of
fd's and try to close them one by one.
I haven't looked into this specific QEMU bug, but thought I'd mention
the problem above just in case.
Cheers,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
