Why do you stumble up on holes, when all you need to know to make a daemon is described in APUE in detail and in hundreds of books and articles? Making a daemon, either via systemd or a classical way, is learning something new.
"We need a process without a process group, session, controlling terminal and mount point. How to do that? Well, fork two times, setsid, chdir, close all descriptors. Let's call that daemon for short."
If one does not understand what all of this really means, or why all of this is part of a question, who do they blame against learning something new?
And why, pray tell, must this logic be duplicated (poorly) in every single "service" application? Isn't the UNIX way "do one thing, and do it well"? Isn't the whole "I, the author of the application, will forcefully disregard the environment the user provided to it" against the UNIX spirit of composability? No UNIX application that I know of re-opens the controlling tty as its stdout — that breaks pipes, so is heavily discouraged and nobody does that. Well, "daemonizing" breaks job control/child process control/service managers, and yet people insist on doing it.
Not everyone insists on daemonizing, and not everyone nails their services to whatever popular environment there is. Make it a standard then complain. My point is that doing that also is "learning something new", as opposed to "being a luddite disrespecting our systemd". I'm using systemd and other service managers on all linux instances that I have and with all self-written services, btw, it's just this cool kid stance that bothers.
Also I just downloaded the recent sources of sshd and it does daemon(0, 0) under the hood, unless -D is passed. ssh.service just runs it with -D, so what's the deal? Does one function call for the case when systemd is not there break some religion?
Forking however many times you want is not going to guarantee that your are spawning a daemon. The process will end up being owned by its nearest sub-reaper, which could in theory still be owned by the initial session.
That implies that daemons always start from a login session and under a process which does this specific trick. That's not true, unless you explicitly wanted them to malfunction.
My point was not that this happens often, but that it is not guaranteed to work (whereas adding your daemon as a systemd service unit is, on systems using systemd).
Also, if you're not starting from a login session, do you really need to double fork?
"We need a process without a process group, session, controlling terminal and mount point. How to do that? Well, fork two times, setsid, chdir, close all descriptors. Let's call that daemon for short."
If one does not understand what all of this really means, or why all of this is part of a question, who do they blame against learning something new?