I've very little to criticise it as an init system... My criticism falls more towards the issues of "why is this all in one process not task specific child processes launched by a core init process" and "why can't you make this work on BSD" and "why the f%*^# hell are you building kdbus... Please stop killing the kittens"
Systemd does not run on BSD because of Cgroups and that is something the BSD maintainers don't want. Here's a small set of justifications why : systemd leverages core Linux infrastructure that has already diverged from OpenBSD
http://lwn.net/Articles/524920/
Having said that, there is work that the systems is sponsoring a project that implements systemd on OpenBSD
Systemd on the other hand is rightly couples to the Linux kernel (to the point that you may have to update systemd and the Linux kernel in lockstep), and its many sub-systems are tightly coupled to the existence of systemd-pid1.
This makes systemd a whole other beast from OpenSSH.
I guess I can explain my 'imaginary' problems a bit. Like normal people, I had several random things thrown in rc.local(set drive power settings,disable blue tooth on laptops, set raid sync rates,ect).
The first issue was, systemd never even executed this file. I had to go do random googling just to get it to execute.
After that, it was hit or miss on whether everything within the file would even get successfully executed. I'm guessing because some dependencies or modules aren't loaded yet, which shouldn't matter since rc.local is normally ran last. Sure, I could take each individual command and make its own init file which is what systemd docs recommend over rc.local. But seriously, why should I have to go to that length to fix something that has been working fine for 15 years?
It was not my intention to flame you. From your tone and sparse message, I assumed you were making yet another unfounded accusation about systemd; so many people on both sides (but mostly on the anti-systemd side) have been making ridiculous and untrue statements so often and for so long that I tend to just expect random made up nonsense to fly with reckless abandon. In your case, you have had a bad usability experience with systemd; and I can't deny your experience. I wasn't there.
That said, it is my understanding that rc.local continues to work fine on systems that choose to enable the compatibility layer. Fedora is my desktop and laptop OS of choice, and I don't think I did anything to make my rc.local files work. I don't use them for much, but I do have some custom hard disk spin down times and such setup on one of my machines, which continued to function after upgrading to a systemd-based version.
If your distro opted not to enable the compatibility layer by default, I suspect there's an easy way to do it yourself with a single command line or installation of a package.
Our servers all run CentOS and we've put a couple of new CentOS 7 systems online recently, and while we don't have any rc.local bits running on them, we do still have a few old style initscripts (in our products, embarrassingly enough, even though our bootup and shutdown module supports systemd and upstart, we still ship initscripts to start our own stuff), and they have continued to function correctly on CentOS 7.
In short, it has not been my experience that doing things the old way has been dramatically cut off for people who need to continue doing so for the time being. In my, admittedly limited, experience, I haven't noticed any difference except the "service" command now recommends systemctl when you run it.
In summary, systemd has not simplified my life. I am not really sure what the rave about it even is. And no, I am not the one threatening the developers. I really don't care enough. I just find it odd that so many praise it so heavily, and I don't feel that way at all. I also know of no sysadmins that are looking forward to its global rollout....
Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).
I've been a UNIX/Linux system administrator coming up on 20 years now (professionally since about '99), and I understand the pain. It's hard to break the habits of all that time; it's always worked before. In a pinch we've always been able to stick some shell commands somewhere and have it fire up the stuff we wanted to fire up.
But, it's nice to have one "thing" to ask questions of that will tell us a significant amount of data about the state of our system. It's something Windows Server has had for a long time (for Microsoft-provided core stuff; third party stuff has always sucked way worse than the state of things on Linux has ever been), and was arguably one of the (very few) reasons one might choose Windows over Linux on a server.
I have reservations about systemd. It's big, seemingly over-engineered and intrusive into places that init never went, and does some things in seemingly fragile ways (someone else mentioned that dependencies failing can lead to failure to boot, which is not something init ever really had a problem with). But, it's better than init, on nearly every axis. And, it is the new de facto standard.
So, I will learn it. I will work to make all the software I work on (which has an installed base in the millions, in the case of Webmin) work well with it. And, I'll probably even come to like it, eventually.
Yes! Exactly! When you start breaking people's stuff that was working you will certainly not be getting compliments!
~$ grep -r 'rc\.local' /lib/systemd/system
/lib/systemd/system/rc-local.service:# systemd-rc-local-generator if /etc/rc.local is executable.
/lib/systemd/system/rc-local.service:Description=/etc/rc.local Compatibility
/lib/systemd/system/rc-local.service:ConditionFileIsExecutable=/etc/rc.local
/lib/systemd/system/rc-local.service:ExecStart=/etc/rc.local start