In process model standard (typically one fork per connection). But the problem is that in the child process we only close the socket the new connection arrived on. Any other socket/file descriptors are still open in the child. This is not nice for the LDAP server where we listen (at least) on 8 sockets ports 389, 636, 3268, 3269 on ipv4 and ipv6. In that case a child also has 7 of them + the new one for the new connection. But this is really bad for the "mixed" process model we use for DCERPC. Typically we listen on ports 135, 49152, 49153 and 49154. For connections on ports 135, 49152 and 49154 we use a single process model and keep the connections open in the same process that also listens on the sockets. But for connections on port 49153 (to the netlogon server) we fork a process per connection. And each of these child processes inherit *all* socket/file descriptors of all connections in the parent. So even if connections are already closed in the parent, the child keeps it open until the child real connection is also closed. As a result a have high numeric value of the socket/file descriptors in all processes, even in child processes which are just supposed to handle a single connection. The gpgme library uses select internally and gets file descriptors with a value > 1024. I actually saw values around 2800. We hit an assert in glibc's __fdelt_chk() => __chk_fail(). This is clearly a bug in gpgme, but it's also very bad to waste these resources in Samba.
I am so sick of crap software that still uses select() - IT WILL NEVER SCALE. How do people get away with shit like this in 2018 ? We should ban dependencies on utter rubbish :-). We're only using it in one place, can't we replace it ?
(In reply to Jeremy Allison from comment #1) It's open source we can just fix it. git://git.gnupg.org/gpgme.git src/w32-glib-io.c already seems to have some kind of poll() usage, we need to port that to src/posix-io.c But still this bug is more about our glory of leaking file descriptors... :-)
Yeah I know we can fix it, but that's not the point. How long before our fixed version shows up in distro's ? Yes, we need to fix our fd-leaks too :-).