No idea why software tries to "daemonize" anyway. Seems to be some kind of weird tradition. It's always been the wrong thing to do. They should just run normally and output to standard streams even if it's connected to a terminal. The reasons are outlined here:
https://mywiki.wooledge.org/ProcessManagement
Ironically, systemd is one of few service managers which can properly track those weird "daemonizing" processes. It uses Linux's cgroups. It doesn't matter how many times they fork, they can't hide from systemd.
mydaemon & daemonpid=$!
- you ssh'd into server, restarted server, checked it worked. Then you logged out and server got killed.
- your server runs as root or power user
- your server output/error goes somewhere, not clear where
- your server's process got paused by SIGTTOU, because it was trying to write to console
etc...
The complex daemonization dance, with double-forks, closing random FDs, etc.. was required to avoid all this bad stuff before systemd days. Sysvinit/openrc folks came up with "start-stop-daemon" helper, but it was pretty terrible in general, especially in logging department (it had none).
The point is software should be written to make the service manager's job as easy as possible by keeping it simple.
I disagree that systemd is a proper service manager. Systemd is horribly complicated in comparison with what is actually needed to implement a proper service manager, as demonstrated e.g. by D. J. Bernstein's daemontools and their many derivatives.
Perhaps systemd is better these days, but a few years ago when I have tried systemd on one of my servers I have stumbled upon a bug that could be explained not by some random programmer mistake but only by a bad global architecture of the program. That bug made me mistrust the competence of the systemd creators, so I have never tried to use it again. Moreover, systemd does not provide any feature that I could consider useful and that is not available in alternative service managers, so there were no reasons for further experiments with it.
(That systemd bug was a bug that I have never seen in a computer without systemd, from the mainframes of 50 years ago to the latest computers, regardless of the operating system. Due to a race condition in systemd, sometimes the shutdown or reboot of a computer could fail, with the computer remaining stuck in a deadlock, i.e. in an infinite loop, without properly saving all state and closing all resources.)
You might not need the features, but someone does, and putting it all in one places means everyone can use the same tool, and nobody has to learn 10 different systems for slightly different tasks.
Hence the hate that systemd has, and always will have, as long as there exists a community of people who use Linux because it is a Unix-like operating system.
But, Linux is versatile enough that everyone can have their own little fiefdom. The real rage came in years ago when tools that were widely used by all suddenly became reliant upon systemd to function at all. Thankfully, in the time since, enough development has happened that mostly people are free to choose what they do and don't want to run again. The manner in which it was foisted upon the community, however, was one that hopefully will be remembered as being far more aggressive than should be repeated in the future.
But, I imagine that as long as Lennart Poettering walks the Earth, we likely will have yet another similarly awful episode.
Seems like we're in a pretty good place now, with separate development efforts by and for the people who are actually interested in anything but systemd.