[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: bb_daemonize_or_rexec(DAEMON_CLOSE_EXTRA_FDS) does not close extra fds
From:       Arnout Vandecappelle <arnout () mind ! be>
Date:       2019-03-20 10:40:50
Message-ID: 4848ad1e-1fb0-0872-16de-0b08c36a7268 () mind ! be
[Download RAW message or body]



On 15/03/2019 10:30, Denys Vlasenko wrote:
> On Thu, Mar 14, 2019 at 4:35 PM Arnout Vandecappelle <arnout@mind.be> wrote:
>>  I've noticed that bb_daemonize_or_rexec(DAEMON_CLOSE_EXTRA_FDS +
>> DAEMON_DEVNULL_STDIO) does not actually close all fds. This is what gets called
>> by start-stop-daemon -b, so it means that start-stop-daemon will propagate all
>> non-CLOEXEC fds from the parent.
>>
>>  To test:
>>
>> sh -c 'exec 3>&1; busybox start-stop-daemon -S -b -x /bin/sleep -- 10000'
>> ls -l /proc/$(pidof sleep)/fd
> 
> Does debian ssd close fd#3 in this case?

 Yes, Debian ssd does that. It uses:

 static long
get_open_fd_max(void)
{
#ifdef HAVE_GETDTABLESIZE
	return getdtablesize();
#else
	return sysconf(_SC_OPEN_MAX);
#endif

[snip]
> Yes, there is no easy way to close all fds. Usually people go with
> something like
> 
> fd = 1024;
> while (fd) close(fd--);

 That should be while (fd > 2) of course + the existing break.

 So, do we go for 1024, sysconf, or getdtablesize? Or just ignore the issue?

 I don't really see the point of getdtablesize though.

 If sysconf, should a function be added to libbb/sysconf.c to wrap it?


 Regards,
 Arnout

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]