Been using since the late 90s.
Debian was always exceptionally stable with sysvinit. Certainly moreso than systemd ever has been.
Yes, sysvinit had issues. Yet you could fix those issues quite handily. The core init binary was small. The scripts individual, and issues readily addressed. And once you resolved an issue, you reported upstream and debian typically fixed.
Meanwhile, systemd has an entirely new litany of problems with every single release. It's an insanely fast moving target. And worse, due to the nature of the project, it keeps extending its scope, and when it does so, it does it in what I can only refer to as a half-assed way.
Want nuanced DHCP services? Have to disable systemd's builtin, and go with an external. The same is true for ntp, have to disable that and go with ntpd. When it comes to mounting NFS services, I've had systemd:
* prevent a proper shutdown
* prevent a proper startup
* fail to mount on user login
* fail to start other services, because nfs is down
Meanwhile, nfs /home may have been an issue in certain circumstances... but there were very simple, very easy ways around this. And any breakage was simple to deal with.
I guess my point is, you may have had problems with whatever you used prior, but many distros ironed out most of the kinks. And the init system wasn't, essentially, an entirely new init system every 2 years.
Systemd has so many tweaks in its code now, so many edge case fixes, so much scope and size, overlaid with so much constant change, that it is essentially easier to consider it an entirely new codebase, every new stable release of a distro.
That's the complete opposite of stable.
What really should be done, IMO, is fork systemd and:
* remove every single thing that isn't core init
(No network code, no dhcp code, no ntp, no udev, nada, nothing)
* stabilize and simplify that core code
* anything of potential value, and save it as a separate
code base, maybe keeping systemd's udev or some such
I mean, look at binary logfiles, and having its own internal logging system. It's just insane. I literally cannot comprehend the logic of this. Now almost every single linux system in use, has two parallel logging systems. systemd's silly system, and then a syslog variant.
Just... why?
It's the same as the entire network blather, claiming naming conventions are more simplistic. Wha?! Before systemd, debian's udev implementation would give you eth0 for all but edge cases. It would retain knowledge of what NIC had which label, keep that through boots, no matter where you placed that NIC. It worked, it was perfect, it was simple, it had zero issues, for a decade plus.
Yet today, I still get insane interface names such as 23423434234weesa34r325233rwef from systemd in some cases. Hello?! What?! How is that a "predicatable" name. You know what's predictable? eth0.
Not some insane 'name it after the NIC slot, or then the MAC, or then the $x, onward forever.
It is immensely clear that systemd authors had very little understanding of server use linux when they started. And all of their goals were primarily, at the time, to "speed up" booting of VMs, to make VM instantiation of network easier (hence, naming after PCI(e) slot, which can be set in hypervisor configs).
Meanwhile, sysvinit had parallel bootups, and all systemd bootup optimization speed is gone, because systemd had to take into account all of the issues that sysvinit had to.
What a shocker. I recall systemd devs toting how fast stuff booted, then spending a decade adding edge cases, adding the ability to prevent instant reboots (eg, proper shutdowns so DBs and other daemons can exit gracefully), and wow, look at that, now bootup times and shutdown times are slower than sysvinit systems I manage.
Yes, slower. Along with cases of systemd not rebooting, just doing a shutdown and failing to reboot, because systemd. Literally the most absolute worst thing an init system can ever fail at. Pathetic. Beyond pathetic.
It's at least once a month I have to deal with a new systemd edge case. Literally, once a month. Yet when I managed non-systemd systems? Years would go by before an edge case hit, I'd resolve it, and done for years.
I don't know why you would distrust old init systems. Their scope was quite simple. Outside of starting/stopping a service, that was it. And outside of something more complex (shutting down a DB, and maybe a 4 minute wait for that), this was a very simple task.
What issues did you have? NFS boot issues (an easy thing to resolve, but yes this was and still is an issue, even with systemd).