9

I've read and understood about how you create a daemon process, but from everything I read I never really understood why it needs to be done.

I've read that we do the fork - setsid - fork to avoid the process to gain control of a terminal, but what does this mean ? If I start a program in the background using & (for example './script &' ), what makes this process' execution different than if I ran normally a program that turns itself into a daemon ?

Does this simply mean that if I logout the background process will stop and the daemon will keep running ? I'm really having trouble understanding the 'gain control of a terminal' thing.

The reason this bothers me is because I'm working on an embedded RPi on a robot and I thus need to make programs start on boot. Currently I'm just starting them from rc.local with a command like this su user -c 'python /home/user/launcher.py &' &. I've never had any problem with the program starting on boot (I can even see the process using ps -e when SSHing to the RPi), but I would like to know if there's any risk / if it's bad practice.

lesurp
  • 193
  • 1
  • 3

1 Answers1

7

That's more than one question, each could have long answers. Briefly

  • If I start a program in the background using & (for example './script &' ), what makes this process' execution different than if I ran normally a program that turns itself into a daemon ?

    Running a program in the background, it no longer is directly controlled by the terminal (you can't simply ^C it), but it can still write to the terminal and interfere with your work. Typically a daemon will separate itself from the terminal (in addition to forking) and its output/error would be redirected to files.

  • Does this simply mean that if I logout the background process will stop and the daemon will keep running ?

    The background process could be protected with nohup but unless its output were redirected, closing the terminal would prevent it from writing, producing an error that likely would stop it.

  • I would like to know if there's any risk / if it's bad practice.

    Besides the problem of keeping track of the program's output (and error messages), there's the problem of restarting it if it happens to die. A service script fits into the way the other services on the system are designed, providing a more/less standard way of controlling the daemon.

Community
  • 1
Thomas Dickey
  • 75,040
  • 9
  • 171
  • 268
  • 1
    Thanks ! That was clear. Now I realize I don't really understand how rc.local works as I'm able to start programs from it and they work well although they have an output. Are rc.locals stderr/stdout fds redirected to /dev/null by default ? – lesurp Jun 05 '16 at 15:17
  • 1
    That will probably come out on the system console, e.g., `/dev/tty1` (some systems differ). – Thomas Dickey Jun 05 '16 at 15:18