Here is an explanation of where fs.nr_open = 1073741816 is coming
from: https://access.redhat.com/solutions/1479623.
The limit on Debian stable is not 1024. It is 1024 * 1024 = 1048576.
On Tue, Aug 20, 2024 at 3:19 AM Michael Tokarev <m...@tls.msk.ru> wrote:
>
> Control: tag -1 - moreinfo unreproducible + confirmed upstream
> fixed-upstream
>
> On 8/20/24 01:14, Sergio Durigan Junior wrote:
> > 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.
>
> > Although this is a different issue, it reminds me of
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075871, which is a
>
> This is interesting, yes.
>
> In qemu, we've a code which uses close_range() or failing that,
> iterates over /proc/self/fd/ and closes everything found there.
> If /proc/self/fd/ isn't available, it just does nothing.
>
> This is one part.
>
> However, in qemu up to 9.0, there's another code in net/tap.c:
>
> static void launch_script() {
> ...
> int open_max = sysconf(_SC_OPEN_MAX), i;
>
> for (i = 3; i < open_max; i++) {
> if (i != fd) {
> close(i);
> }
> }
>
> that's the thing we're seeing.
>
> -netdev tap,script=no will fix it for startup, but it will
> still try to do the same at shutdown unless downscript=no
> is also specified.
>
> In 9.1, this code is changed to use close_range() and
> /proc/self/fd/ too, in a more generic way.
>
> My previous comment still stands, - in my view such attempts
> to close things are nonsensual.
>
> Thanks,
>
> /mjt
