2

I created a script which is supposed to run as a daemon, controlled by systemd. I came across ancient questions like What is the reason for performing a double fork when creating a daemon? and ancient documentation, which suggests that daemons should fork to detach from a terminal.

But in 2020, using systemd, all of this seems obsolete to me. As far as I understand (with support from https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html), there is no need to detach from any terminal, no need to avoid zombie processes etc. The whole forking-and-exiting only makes sense to me if I want to start the daemon manually from a terminal and not with systemd.

Am I right or is there still any benefit from forking inside a daemon and exiting the parent?

dr fu manchu
  • 618
  • 5
  • 10

1 Answers1

1

You are correct. The forking is now 100% handled by the systemd environment so there is really no need to do anything in that arena. It even saves the PID which you can access in the StopExec=... as $MAINPID:

StopExec=/bin/kill "$MAINPID"

If your daemon has a forking capability, you can use it with the forking type:

[Service]
type=forking

But if you don't have any forking mechanism in your daemon, don't implement it. It's useless.

Note that from the command line, you can always use the & to start it in the background. That's explicit. People can clearly understand how that works.

Another point, many people would use a PID file to save that identifier and use it to kill the process on a stop. That PID file was also useful to prevent the administrator from starting a second instance of the same service. Again, systemd takes care of that. You can have at most one instance of any service.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156