0

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.

Improve this question
0

1 Answer 1

Reset to default
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.

Improve this answer
5
  • Thanks, I didn't ask how a shell executes an external command in general. Commented Dec 27, 2018 at 22:09
  • The point is in the last sentence: you seem to take the process of daemonisation as the norm. Commented Dec 27, 2018 at 23:18
  • I didn't. Please reread my post. Commented Dec 29, 2018 at 2: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. Commented Dec 29, 2018 at 13:26
  • That's my typo. Commented Dec 29, 2018 at 13:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.