"wait for the service to be active" Well, how do you do that ? The service needs a way to to say "I'm done initializing and are now up and ready". That's not the way a lot of daemons are written today. They normally fork twice (or calls the daemon() function) and then starts initialization.

Looking through all the current init scripts, almost none of them do that. They launch the service executable, and report success it that succeeded. The service then often fork to place itself in the background, starts initialization, and might fail at that point without the init system noticing it.

The "forking" option of systemd will do the same, which is reasonable since a lot of existing services already works that way.

The apache init script on my system is one of the exceptions though, it doesn't directly launch apache, instead it starts apachectl, a program specifically written to start and interact with apache. That program communicates with apache, and therefore knows when it's started, whether it failed because httpd.conf had an error and so on.

That's not a general approach - unless you want to have each service accompanied by a program capable of doing IPC with the service for use with e.g. startup and shutdown. That'd make services portable among init systems and operating systems, so if you need that, it's a reasonable approach.

For systemd you'd can do the same, run apachectl to start apache.

This, just because OP can't figure out how to forking doesn't somehow mean systemd screwed up.

Either the socket activation or notify approach don't need linking against a systemd library either they can just be done in < 20 lines of code.

Based on my previous experience working on an init replacement, "forking" is probably not flexible enough. It turns out there are just enough daemons that either don't fork or fork but don't exit, but where you still need to wait for a pidfile, that it's a bad idea to assume one implies the other.

Note the irony of the situation. Writing an init.d script is actually really hard. A post attacking Systemd is actually a pretty good argument for using it.

The common argument that systemd makes init jobs unportable sounds quite funny to me. I've used a lot of *NIX systems and init.d jobs are anything but portable, unless you fill them with OS-specific hacks.

The issue isn't that systemd makes init configurations unportable, it's that it makes programs unportable by tying them to systemd. What do we do 5 years down the line when we realise systemd was a bad idea and want to replace it with something else?

We have that something else, or maybe another component of the system implement the systemd notify api?

systemd has a vast number of APIs, especially inter-component ones, which are unstable and undocumented, meaning you'd have to replace the entire thing wholesale if you didn't want certain parts of it (especially its PID 0).

The thread we're on is talking about a public API that's not documented sufficiently for alternative implementations to be created without reading its source code.

Also you can, in principle, write a robust, automatic converter of systemd units into init scripts.