You can wire up syslog to the journal.
I don't want to, I don't need to. I just want every bit of information a horribly broken system is still able to tell me about its state. This won't work better is you move away from plain text. - BTW: How do you use remote logging with systemd? Sending and receiving?
So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned?
Yes, really. This is not the most simple setup here (suexec php5/fastcgi), but starting/stopping of the spawned php servers has never been an issue, even without systemd.
Please do not assume that I am too young or too stupid to know the good old ways.
Admittedly, you are making that hard to believe when you even have issues with stopping apache. There is no problem to fix.
Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.
Not really. A few sleep 1, speech-dispatcher has a sleep 3 and stunnel4 sleep 5. Both at restart. I couldn't care less.
By the way, there are alternatives to sysv init. They work well and don't even break compatibility. They are what systemd needs to be compared to.
Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back
Linux and Free Software are about modularity and choice. Large-scale breaking of backward compatibility and user expectations for dubious reasons is not going to play well with the community. Linux is already getting WAY too complex for people concerned with security, and additional complexity in form of enforced blessings by a group of people who comes across as conspirators gives me a very bad feeling. Who profits from intentionally weeding out choice? We'll see, but don't expect me to wait for it.