I think it's an elegant and necessary complexity to save us from much uglier and greater complexity.
Honestly, what kind of complex init system do most /servers/ need?
But the issue is actually that systemd is not just an init system it's steadily increasing in scope to incorporate more and more services.
For example, systemd-timesyncd (controlled with timedatectl) is an excellent NTP system, and after it's been stable for a few years I'll use it with public NTP servers. It takes just one command to get up and running and it keeps your clocks synchronized, what's not to like?
And considering systemd's vs OpenBSD's track record I suppose it's also less likely to get you owned or set your time to Jan 1st 1970 because of some bullshit like "who could have predicted that in 2016 networks are still so bad that UDP can deliver packets out of order".
And, btw, why should an init system come bundled with a time client or a time client bundled with an init system? When can I expect systemd-solitaire?
That's entirely up to distribution packagers. 39k bytes and you get a dead-simple working ntp client daemon (no server) which requires literally no setup. If the distro packagers want to split it out or not include it at all, they can do that and the build system is set up to make that easy.
So it really depends on how you mean "bundled", it's good and there's basically no reason not to include it in the package.
I also figure it's a bit of a straw man to hypothesize a bug which hasn't occurred. NTP, as far as I'm aware, is mostly static structures on the wire. If there's a problem with the client, it's most likely your clock will just be wrong; bad as that is.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/init/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/
Alas there is no OpenBSD-solitaire yet, but who really needs that if you can play "Hunt the Wumpus" instead:
My CentOS 7 OSD nodes will sometimes not complete booting because it's hung somewhere in the boot process. There is no way to tell systemd to continue, Ctrl + C doesn't do anything and there is no way to get into the system because sshd is still not running.
Booting it in debug mode to try and get more information makes the whole thing work.
Also, when a unit file gets stuck, it goes into this waiting loop, which is a giant pain in the behind... I want to try and fix it, not wait 10+ minutes for the unit files to time out.
Ctrl + C should immediately stop what it is trying to do and dump me into some sort of login shell so that I can then go and fix the issue...
I've also had issues on Ubuntu 16.04 because of third party software that doesn't correctly set up it's Requires/Wants/Before/After's and then systemd will happily hang the whole boot process. Worst thing is that these issues become more and more apparent on systems with more cores/CPU's... so the 44 core, 88 thread systems we have show the issue way more than the 4 thread desktop that developers are using...
Systemd in their infinite wisdom decided that journald can choose when to log and when not to log something. Historically, syslog etc have been a very thin barrier between programs and outputting logs. Journald now decides if and as and when it's going to bother putting logging data to disk.
One of the things they've decided is you don't really need logs when you run the reboot command. In fact, if you really want logs you have to dig in to their documentation to find this: https://freedesktop.org/wiki/Software/systemd/Debugging/#ind...
That tells you to adjust kernel parameters and write a file to disk to explicitly re-enable logging.
I lost a whole bunch of time recently troubleshooting something on a server running systemd that was interfering with the reboot process, because systemd logged sweet FA. I had a pretty good idea what the problem was, but lack of logs made it significantly harder to nail down. The actual problem is one I've run into all sorts of times in the past, and in every non-systemd case, there's always been enough detail in the logs from the init system to nail it precisely from the get go.
How many of those services have dependancies on devices that may or may not be online/attached at any point in time?
The preach of UNIX culture in GNU/Linux sounds to me like emigrants keeping long gone traditions alive from something grandparents used to speak about.
[1] https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
For me, the UNIX philosophy has not been about the tools, but about replaceability. Systemd has made itself nigh on impossible to replace.
The SysV init system stopped being convenient for some number of people, so they replaced it, and it has been a long and horrible process. It will happen again if it needs to.
> But nobody is thinking about that because "init-scripts sucked".
Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for.
Instead of learning from that mistake, systemd just doubles-down on it. systemd will be much harder than SysV to replace because it includes more than SysV stuff. It will happen if it needs to, but why not just make it easy to replace if it needs to? (answer, IMO: insecurities about your product make you want to entrench yourself instead of constantly improve it)
> Well, now they're thinking about it, and talking about it every time they bring up problems with systemd. Those problems and discussions are something that will be brought up when any potential future init system is being designed or advocated for.
Sure, but why not do that now? instead of pushing it off for people in the future to figure out?
Well, I was actually talking about future successors. What systemd did right and wrong at a technical level, as well as at a marketing, design and adoption level, will obviously have been internalized to a greater or lesser degree depending on the aspect being considered and the person doing the consideration.
> systemd will be much harder than SysV to replace because it includes more than SysV stuff.
I don't think so. There are a plethora of other init systems that have either been started in response, and people work out how to get those into these different distributions. The market for init systems is more vibrant than it ever has been, so any eventual successor gets to reap the benefits of everyone's collective experience in this area. Systemd may be overtaking most the large distributions, but let's not pretend the init system in linux, what it interacts with, and what's required to replace some or all of one init system with another aren't far better understood than they were a decade ago.
> why not just make it easy to replace if it needs to?
It may not be easy to replace, but it's far from impossible, and it's getting easier and better understood all the time because of people that don't want to run systemd. That's a good thing.
> Sure, but why not do that now? instead of pushing it off for people in the future to figure out?
Because regardless of how much it seems like people dislike systemd, I'm confident the majority of people either didn't notice, don't care, or like the new features enough to outweigh their dislike of other aspects. I would be happy to consider data that points to an alternate conclusion, but there's a reason why it's taking over, even if there are problematic aspects.
Red Hat would like SystemD to be the init system of record and have - for years now - been subsuming other utilities, daemons, logging, su, etc. in order to make it the obligate choice.
Any technical gains from the integrations seem secondary to the control this gives them over the direction of Linux as a whole.
This is obvious dirty pool.
If they'd gotten where they were on the merits, I think people would be a lot quieter.
Beyond the political stupidity, systemd has made itself a single massive and opaque point of failure, especially since it ate logging.