7

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.

closed as too broad by Thomas Dickey, cuonglm, Anthon, Stephen Kitt, garethTheRed Jun 6 '16 at 6:25

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

4

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.

  • 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 5 '16 at 15:17
  • That will probably come out on the system console, e.g., /dev/tty1 (some systems differ). – Thomas Dickey Jun 5 '16 at 15:18

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