Open goudunz1 opened 2 days ago
this is init.c:setup_file_descriptors()
. we should see if closefrom()
is available (via configure-time test) as that'll be way more efficient.
this is
init.c:setup_file_descriptors()
. we should see ifclosefrom()
is available (via configure-time test) as that'll be way more efficient.
Thanks for your time! I'll just run the container with a relatively small nofile limit for now.
Dear developers,
I observed a very strange behavior after I compiled xinetd version 2.3.15.4 and hosted a test program in an Alpine docker container: xinetd was stuck and kept consuming 100% CPU for about 2 minutes before it was able to bind to the specified port.
After some debugging with strace and ltrace, I found that xinetd fell into a very long loop during initialization:
I think the problem is that xinetd only checks whether the nofile limit is RLIM_INFINITY during file descriptor setting. However, on my platform the default nofile limit is set to 0x3ffffff8 (1073741816), despite RLIM_INFINITY being -1. xinetd tries to clean all the file descriptor from 3-0x3ffffff7 during initialization, which leads to a 'forever' loop.
src/init.c (line 152)
Running the container with
--ulimit nofile=4096:4096
and there's no stuck. It seems like changing line 152 torl.rlim_max > MAX_FDS
could be a proper fix.I'm not sure whether this issue counts as a bug because fixing it does changes xinetd's default behavior a little bit. I know the original intention is to use a larger nofile number other than MAX_FDS(4096), but when nofile limit is set to a large number other than RLIM_INFINITY, the initialization will become extremely slow and CPU consuming.
My host platform:
Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
My container:
Alpine Linux 3.20.3
The dockerfile I used to compile xinetd 2.3.15.4:
xinetd.conf
I used:xinetd command I used:
xinetd -stayalive -dontfork
Hope to hear from you soon.