Why do some programs' processes exist after forking a child, without the child starting a new process session?

Question

Here are some of the steps for creating a daemon process from a given process,

the given process exists soon after forking a child,
the child calls start a new session and also a new group, by setsid()

But I seem to find cases with only the first step without the second step:

What is the purpose of only having the first step without the second step?

Does it not want to create a daemon but something else?

Thanks.

score 0 · Answer 1 · edited Dec 27 '18 at 19:04

0

The purpose, on high level, is best seen in the bash example that you gave. When, in an interactive bash shell, a normal user types ls, what happens is

Bash forks
the child process execs ls
when ls is finished, the child process ends

It would be silly to daemonize ls, because (in general) it ends very quickly.

Furthermore, it would also be strange is all processes that are forked from a shell would do a setuid(). You would then not be able to run a shell as a normal user.

Do not take the specifics of daemons as the general rule for the use of fork/exec.

edited Dec 27 '18 at 19:04

Tim

101,790

answered Dec 27 '18 at 18:51

Ljm Dullaart

4,643

Thanks, I didn't ask how a shell executes an external command in general. – Tim Dec 27 '18 at 22:09
The point is in the last sentence: you seem to take the process of daemonisation as the norm. – Ljm Dullaart Dec 27 '18 at 23:18
I didn't. Please reread my post. – Tim Dec 29 '18 at 02:49
"Does it not want to create a daemon but something else?" The answer then is "something else". I also noticed that you changed setuid() in your question to setsid(), which makes my remark about setuid() no longer applicable. – Ljm Dullaart Dec 29 '18 at 13:26
That's my typo. – Tim Dec 29 '18 at 13:28

Why do some programs' processes exist after forking a child, without the child starting a new process session?

1 Answers1