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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24869 in the body.
You can then email your comments to 24869 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; Emacs should not force lower FD limit on subprocesses
Date: Thu, 03 Nov 2016 19:10:40 +0100

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Brendan O'Dea <bod <at> c47.org>, Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24869-done <at> debbugs.gnu.org
Subject: Re: bug#24869: 26.0.50; Emacs should not force lower FD limit on
 subprocesses
Date: Sun, 6 Nov 2016 22:58:32 -0800

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.

Previous Next

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