Ticket #2220 (closed bug: duplicate)

Opened 5 years ago

Last modified 5 years ago

Subprocesses do not close open FDs

Reported by: Baughn Owned by:
Priority: normal Milestone:
Component: libraries/process Version: 6.8.2
Keywords: Cc: sveina@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

When creating a subprocess, for example with runInteractiveProcess, only pipes that are created in the process of creating the process are closed appropriately; any FDs created elsewhere in the program are ignored. As unix pipes are only considered closed once every process that could conceivably write to one has closed it, one consequence of this is that programs that rely on detecting EOF will be unable to do so. Another is that the system may leak FDs over the runtime of the program, conceivably running out.

As an example, this makes it impossible to write a fully functional shell with pipes in GHC; in a shell command like "<main program> | cat | cat", the second cat may acquire a reference to the pipe used for writing to the first one, which will prevent that pipe from ever being considered closed.

A brute-force solution would be to attempt to close every possible FD when creating subprocesses. This is undesirable for several reasons - most obviously performance, but also because there are legitimate reasons to pass FDs other than stdin/out/err to a subprocess. A more elegant one would be for all FDs opened by any means to be marked as close-on-exec on creation, and provide a call to clear this bit if transferring it to a specific subprocess is desired.

Attachments

Main.hs Download (1.3 KB) - added by Paczesiowa 5 years ago.
failing code of pseudo-shell

Change History

follow-up: ↓ 5   Changed 5 years ago by Baughn

If setting FD_CLOEXEC (close on exec) is picked, then.. since it has to be set in a separate call after opening the FD, there is a potential race condition if any other thread calls exec. Probably only one OS thread should do I/O or forks - my understanding is that this is already the case, but it had to be mentioned.

Changed 5 years ago by Paczesiowa

failing code of pseudo-shell

  Changed 5 years ago by Baughn

  • cc sveina@… added

  Changed 5 years ago by simonmar

  • status changed from new to closed
  • difficulty set to Unknown
  • resolution set to duplicate

See #1780, and the discussion on haskell-cafe that is linked from it.

  Changed 5 years ago by simonmar

  • component changed from Runtime System to libraries/process

in reply to: ↑ 1   Changed 5 years ago by duncan

Replying to Baughn:

If setting FD_CLOEXEC (close on exec) is picked, then.. since it has to be set in a separate call after opening the FD, there is a potential race condition if any other thread calls exec.

Note that on Linux, as of version 2.6.27, this can be done without any race condition. See  http://udrepper.livejournal.com/20407.html

  Changed 5 years ago by simonmar

  • architecture changed from Multiple to Unknown/Multiple

  Changed 5 years ago by simonmar

  • os changed from Multiple to Unknown/Multiple
Note: See TracTickets for help on using tickets.