🚀 go-pugleaf

Charles Richmond <nume...@aquaporin4.com> writes:

> On 7/7/2018 6:16 PM, Joe Pfeiffer wrote:
>> Charles Richmond <nume...@aquaporin4.com> writes:
>>
>>> On 7/6/2018 8:00 PM, Dan Espen wrote:
>>>> Charles Richmond <nume...@aquaporin4.com> writes:
>>>>>>
>>>>> Can an unsuccessful exec() call return???  And where would it return to???
>>>>
>>>> The answer is in the man page:
>>>>
>>>> RETURN VALUES
>>>>     If a function in the exec family returns to the calling process image,
>>>>     an error has occurred; the return value is -1 and errno is set to
>>>>     indicate the error.
>>>>     
>>>
>>> The calling process for exec() must be the child process.  ISTM the
>>> child process must signal the parent process and abort... if exec()
>>> fails.
>>
>> There is no requirement that there even be a child process.  There is no
>> reason a process can't replace its own running image using an exec().
>>
>
> Yes, of course... isn't that what any process hopes to achieve by
> calling exec()???  I assume a process could even re-load its *own*
> image using exec().

You're the one who said the child has to call exec(); I was pointing out
that there's no requirement that there even *be* a child.

>> If it's a normal fork&exec, the child process can just exit() (presumably
>> with an error return code) and the parent will find out about it in any
>> of the ways already available (including, of course, SIGCHLD).
>>
>
> But if tye parent process exits before killing the child... you could
> end up with a "zombie" process.  ISTM that SVR4 Unix had system calls
> that would allow the child to exit (and die) without parental
> approval...

You're talking about an orphan.  A process is a zombie when it has
terminated and its parent has not yet reaped it.  An orphan process is
reparented; init becomes its parent.  I can't think off hand of a call
that would assign a child to some other parent than that.