Should a well-behaved daemon daemonize itself?

Question

In this answer, it is mentioned in passing that it is not appropriate for a daemon process to reparent itself to init with the double-fork-and-exit trick. The answer links to a website which is no longer live but I found it on the Internet Archive. It lists a number of reasons for this which boil down to "You should not daemonize because it might break init or other tools that don't expect daemonizing, and if someone is running it interactively, they should use & or nohup to explicitly ask for backgrounding." These reasons do sound rather convincing, actually, since a properly-configured daemon should already be running in a sane environment by the time it receives control. (Well, ideally it's running in a container with lots of fancy automation, but that's another story.)

However, I don't understand why we have setsid(2) if we're not supposed to use it. I can understand setpgid(2); you need that to implement a (modern(ish)) shell, but it seems like the only way to reliably call setsid(2) is to daemonize, and the man page even tells you to do this. I suppose you might use it to implement various low-level tools which eventually run login(1), but setsid(2) is not a privileged system call and its man page makes no mention of this use case. The Python folks, at least, seem to think daemonizing includes reparenting, and I've seen this attitude in a number of other contexts (particularly academia, such as the textbook which that PEP cites).

As yet another point of reference, daemonize(1) and daemon(3) are things (on some systems), and the former's man page says this:

Most programs that are designed to be run as daemons do [various things including reparenting] for themselves. However, you'll occasionally run across one that does not. When you must run a daemon program that does not properly make itself into a true Unix daemon, you can use daemonize to force it to run as a true daemon.

What is the correct behavior for a daemon on startup, and in particular, should it reparent itself?

Answer 1

I always thought setsid() and session leaders had to do with process control and how signal delivery with terminals work. They are one level up from process groups.

An answer on Stackoverflow refers to POSIX.1-2008, which says:

3.339 Session

A collection of process groups established for job control purposes. Each process group is a member of a session. A process is considered to be a member of the session of which its process group is a member. A newly created process joins the session of its creator. A process can alter its session membership; see setsid(). There can be multiple process groups in the same session.

And Chapter 11 goes on to tell how signals are delivered based on process groups and the controlling terminal of the session.

In practice all logically separate "sessions" on the Linux system I looked at, do run under separate session id:s, so login or some other (sshd, screen) does run setsid as you suggested.

---

As for what a daemon should do, I suppose it depends on what init system one uses. On Linux, with traditional System V init scripts the daemon has to go the background itself (or with assistance from a helper). Though with sysvinit, the init scripts might be ran directly from an administrator's shell, and that might not be a clean environment in all cases. (It's possible to inherit e.g. resource limits from the session.)

On Upstart and Systemd, it might be preferable if the daemon did not fork itself, since the init system can do it. (And Upstart in particular does some funny things to follow forking daemons.)

(I don't know about other Unixes, but as @Stephen Harris commented, it might a good idea for a daemon program to support both forking and not-forking behaviour.)

---

Then there's e.g. ssh-agent, that is often run by a user by themselves, without support from the init system. It's quite useful that it can fork to the background (with setsid) and stay alive, so it can be used from multiple shells. (screen windows, xterms...) It also has useful output when it starts, so running it with nohup would be slightly complicated.

Answer 2

A well-behaved daemon should daemonize itself because that's what's expected of a daemon. The daemon should work sanely even if it isn't launched from a daemon-launching framework.

A well-behaved daemon should have an option to not daemonize itself, so that it can be launched from a supervisor. (Recent Linux kernels make it easy to supervise daemons that double-fork, but not every system runs a recent Linux kernel and not every supervisor program assumes a recent Linux kernel.)