Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site hpfcla.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!talcott!panda!genrad!decvax!decwrl!pyramid!hplabs!hpfcdc!hpfcla!ajs
From: ajs@hpfcla.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Orphaned Response
Message-ID: <43900022@hpfcla.UUCP>
Date: Tue, 21-Jan-86 14:55:00 EST
Article-I.D.: hpfcla.43900022
Posted: Tue Jan 21 14:55:00 1986
Date-Received: Thu, 6-Feb-86 05:17:40 EST
References: <642@wjvax.UUCP>
Organization: 21 Jan 86 12:55:00 MST
Lines: 22

> ...is any reliable [way] for the parent to tell if the exec() in the forked
> child succeeded or failed.

Problem:  A parent process forks a child process which does a variety
of environment setups, then execs another program which runs for an
indefinite time (e.g.  a shell).  The parent needs to return zero if all
goes well (just through the exec), or non-zero if any error occurs
(including failure to exec the other program).  How can it tell?

Solution:  Parent opens a pipe before forking, and uses fcntl(2) to set
the F_SETFD (close-on-exec) flag for the write end.  After forking,
parent closes the write-end (parent is a reader), and child closes the
read-end (child is writer).  Parent reads from the pipe, which blocks.
Child writes a message to the pipe and exits if any error occurs,
including exec failure.  Parent gets back either zero bytes (exec
succeeded) or one or more bytes of error information.  This has the
advantage of also being a form of synchronous wait-for-exec.  (Note,
this does NOT detect exec failure AFTER the kernel closes the pipe.
You can't have EVERYTHING.)

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
{ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"