Originally posted by makam
View Post
Either an operator has to take over and take the decision and responsibility on what to do next, or the maintainer of the system and services (distro maintainers for most distros) should have forseen these possible issues and wrote down a better configuration so the services start up properly, or marked the secondary stuff as not important so that systemd will not block boot even if that fails.
But it's not like systemd can't boot at all if there are issues. It just does not do so automatically.
With systemd you can boot to a rescue shell if you append to kernel command line systemd.unit=recovery.target or even systemd.unit=emergency.target (and the system isn't so trashed that even basic stuff does not work), or if the issue is in the graphical desktop you can boot to your distro's shell with systemd.unit=multi-user.target.
Can you do the same if init scripts fuck up? Yeah, yeah you can (you can specify the init script runlevel in the kernel command line, write the number of the runlevel as the last thing in the kernel command line), although I don't know if OpenRC has this feature (it worked in Debian, before the switch to systemd).
But the problem is like how you said at the end of your post, systemd is BULLISH and it created more than a couple of problems for me and many many others. I don't need nor want a nanny init.
It took me 0 months to get on friendly terms with openrc.
Well if he cares so much about the purity of his projects perhaps he should reconsider on how people are adding ridicualous modules that should not be in an init system. I would be fine with systemd if it limited its scope more. Limiting your scope is also a form of purity.
All programs in systemd repo are standalone daemons and run independently of the init system itself (or they are tools), on clearly defined and stable interfaces.
This follows Unix philosophy about modularity and inter-operatibility from the mantra "do one thing and do it well". Each daemon is focused on a specific task, and the whole system can work with or without. They are just kept in the same source repo and where it makes sense they share code (through shared libraries).
Comment