Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#2220 closed bug (duplicate)

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 (1)

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

Download all attachments as: .zip

Change History (8)

comment:1 follow-up: Changed 6 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 6 years ago by Paczesiowa

failing code of pseudo-shell

comment:2 Changed 6 years ago by Baughn

  • Cc sveina@… added

comment:3 Changed 6 years ago by simonmar

  • Difficulty set to Unknown
  • Resolution set to duplicate
  • Status changed from new to closed

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

comment:4 Changed 6 years ago by simonmar

  • Component changed from Runtime System to libraries/process

comment:5 in reply to: ↑ 1 Changed 6 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

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

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