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?
