FTP Server busy waiting when file descriptors are exhausted

[Thomas Rauscher]

> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org] 
> Sent: Tuesday, April 04, 2006 3:09 PM
> To: Thomas Rauscher
> Cc: rtems-users
> Subject: Re: FTP Server busy waiting when file descriptors 
> are exhausted
> 
> Thomas Rauscher wrote:
> > 
> > there has been little discussion so far. I still cannot see a clean
way 
> > to remove pending connections in the listen socket (besides closing
it).
> > 
> 
> I asked a question about the networking stack and the case of no 
> available fd's when in an accept call. I have found the code 
> for RTEMS 
> in cpukit/libnetworking/rtems/rtems_syscall.c:
> 
> 	fd = rtems_bsdnet_makeFdForSocket (so, &socket_handlers);
> 	if (fd < 0) {
> 		TAILQ_INSERT_HEAD(&head->so_comp, so, so_list);
> 		head->so_qlen++;
> 		soconnwakeup (head);
> 		rtems_bsdnet_semaphore_release ();
> 		return -1;
> 	}
> 
> If there is no fd available the socket is placed back on the 
> listen list.
> 
> Is this the best solution for RTEMS ?
> 
> I checked NetBSD's kernel and it will return an error from accept if
the 
> number of fd's for the process has reached its limit. A log message is

> generated. If there is no space the fd allocator blocks waiting. It 
> looks like FreeBSD is the same.
> 
> If you limit the number of fd's as task has (ulimit), use up the fd's
in 
> a similar way as the test case then try and accept a 
> connection the same error will appear. How-ever on Unix the machine
should not 
> have locked up just the task.
> 
> Possible solutions are:
> 
> 1) The proposed patch.
> 2) Drop the connection if no fd is present (close the socket 
> placed on the listen queue).
> 3) Block in the fd allocator (rtems_bsdnet_makeFdForSocket) 
> until an fd appears. This could be for-ever or just a period of time.
> 4) Other suggestions.

Sorry for my last mail, I accidentially hit the Send Button too fast ...

I would go for 2 or 3. Unfortunately I didn't find too much information
how the behavior should be. E.g., the Linux accept man page states
that ENFILE and EMFILE can be returned. I think there is no waiting or
recovery there.

If we implemented 3, the ftp server would not need any changes. If the
timeout
variant is taken, this would be equivalent to adding the sleep to the
error path in the ftp server loop. It would also prevent other servers
to
go crazy when running out of file descriptors.

I wouldn't block forever, as some applications might want to 
interpret an out-of-fds situation as a critical failure.

Regards,
Thomas Rauscher

--
Thomas Rauscher
LOYTEC electronics GmbH