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?



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.

  • 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. Dec 27 '18 at 23:18
  • I didn't. Please reread my post.
    – Tim
    Dec 29 '18 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. Dec 29 '18 at 13:26
  • That's my typo.
    – Tim
    Dec 29 '18 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.