bug#24869: 26.0.50; Emacs should not force lower FD limit on subprocesses

bug#24869: 26.0.50; Emacs should not force lower FD limit on subprocesses

[Philipp Stephani]

$ 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.


In GNU Emacs 26.0.50.14 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-10-31 built on localhost
Repository revision: 8e7b1af1d708dcf41695cf3fbeff9d35cdb8e5b6
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Source file ‘/usr/local/google/home/phst/ThirdParty/Emacs/lisp/gnus/message.el’ newer than byte-compiled file

Configured using:
 'configure --with-modules --enable-checking
 --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''

Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils shell pcomplete comint ansi-color ring time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 102563 7574)
 (symbols 48 20890 0)
 (miscs 40 346 170)
 (strings 32 19886 5441)
 (string-bytes 1 653021)
 (vectors 16 15180)
 (vector-slots 8 463908 4318)
 (floats 8 189 38)
 (intervals 56 213 0)
 (buffers 976 13)
 (heap 1024 35980 993))

-- 
Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Diese E-Mail ist vertraulich.  Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge.  Vielen Dank.

This e-mail is confidential.  If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments.  Thanks.

bug#24869: 26.0.50; Emacs should not force lower FD limit on subprocesses

[Brendan O'Dea]

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

bug#24869: 26.0.50; Emacs should not force lower FD limit on subprocesses

[Paul Eggert]

Brendan O'Dea wrote:
> A potential fix would be to stash the initial limit before changing it, and
> then restore that limit in child_setup().

Thanks, I did that, and am closing the bug.

> 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.

Crashing is quite bad. I'd rather have Emacs report a reasonable diagnostic 
instead. If Emacs is not doing that, we should fix it.