GNU bug report logs - #24869
26.0.50; Emacs should not force lower FD limit on subprocesses

Previous Next

Full log

Message #8 received at 24869 <at> debbugs.gnu.org (full text, mbox):

From: Brendan O'Dea <bod <at> c47.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24869 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#24869: 26.0.50; Emacs should not force lower FD limit on
 subprocesses
Date: Mon, 7 Nov 2016 16:30:31 +1100

On Thu, Nov 03, 2016 at 07:10:40PM +0100, Philipp Stephani wrote:
>$ ulimit -n
>32768
>$ emacs -Q -f shell
>
>In the Emacs Shell buffer, run 'ulimit -n' again, the limit will be
>1024.
>Internally this limit is required because Emacs uses fd_sets, but it
>shouldn't be inherited to subprocesses.  Probably Emacs should reset
>RLIMIT_NOFILE in subprocesses to the original value.

This behaviour was introduced by the fix to Bug#24325:

  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a5509099484e0762842bc2c9e914779397b91469

Given that child processes will inherit that limit, this causes unnecessary
problems for forked processes (think: M-x compile RET make -j).

A potential fix would be to stash the initial limit before changing it, and
then restore that limit in child_setup().

My inclination however would just be to revert that entire change: AFAICT it
merely moves the problem from emacs crashing under some aberrant behaviour, to
emacs no longer working under that same behaviour due to system calls randomly
failing with EMFILE.

--bod

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.