On Sat, Mar 04, 2023 at 09:38:04PM +0100, Didier Kryn wrote:
> Le 04/03/2023 à 18:44, Hendrik Boom a écrit :
> > One thing I've always wondered about.
> > Why is it necessary to reap orphan processes?
> > Why can't they just terminate by themselves?
> >
>     There are two reasons at least why zombies must be reaped:
>
>     1) every process, even orphanned, occupies some space in RAM
>
>     2) the whole range of process IDs will be used after some time, making
> it impossible to give an ID to a new process, therefore making it impossible
> to create new processes. Only once a zombie process has been reaped, its pid
> is made available again.
>
>     Processes don't vanish when they terminate because the possibility must
> be given to examine the way they terminate, their exit code. The exit code
> tells wether the process has detected an eror or has been killed by a
> signal. This is the way the interactive shell, for example, reports command
> failures: the shell reaps the terminated process, examines its exit status
> and reports errors to the terminal. Every process is responsible of reaping
> its children processes. If the parent process dies before the child, this
> one is called an orphan, as you would expect, and pid1 can and should reap
> it. When a process terminates, its parent, or pid1, receives the SIGCHLD
> signal. There is also a concept of subreaper which can slightly complicate
> this picture.

I see. That's how it works. Now I get to wonder why the kernel cannot detect when a process has no one to report to ...

Well I guess this case has to be handled somehow and this is the way Linux chose to handle it. Maybe Unix too.

Maybe it's desifned this way to avoid baking the treatment of orphans into the kernel. Is there anything else that init might want to do with a terminated process?

-- hendrik

>
>     See 'man 2 wait' for more details.
>
> --     Didier
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng