A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
A traditional SysV init is just fine. Want orchestrated service invocation on startup? Run it from SysV init instead of replacing SysV init.
There is no need to conflate the "sysv rc system" with "sysv init." They are entirely separate things.
In any case, most people wouldn't consider that design "SysV init". The SysV init ecosystem is built around rc files.
The reason to keep these things modular is flexibility and ease of analysis and improvement. The major criticism I see with systemd is that has undefined operational scope and unbounded feature creep. It has no stable interface between components and changes behavior in incompatible and difficult to predict ways fairly regularly. From a systems perspective it's a big ball of mud and the lack of a formal interface makes it prohibitively difficult to change or replace its subsystems.
I don't like that systemd performs ANSI animations on my machine's serial console, for example. Have you seen the "marquee" animations it does when certain services start? I sure would like to force it to print sequential lines of text instead, but I can't.
I don't like that when systemd updated basic utilities like "reboot" I lost the ability to use them in a chroot. Even "reboot -f" which does not need to talk to init. I had to write my own one-liner to call reboot(2) myself not too long ago.
System components need to be well scoped and replaceable. There's a major design problem brewing in this area.
Is it possible to use one without the other?
/sbin/init is pid=1, the single process that the kernel starts when a system boots. It typically runs a command to kick off bringing up userland to the correct runlevel, maybe something like "/etc/rc.d/rc 3". It doesn't do anything more than just execute this command.
The command is part of the RC system. Typically written in shell, it handles walking /etc/rc.*/ and running the scripts contained therein to configure and invoke the various services for a particular runlevel.
You can boot linux using your own init and skip the rc system. From grub, add "init=/bin/sh" to your kernel parameters and you will get a shell as pid=1 and no other processes -- from there you can run commands as you wish to bring your system the rest of the way up. If you were to run "/etc/rc.d/rc 3" by hand you would invoke the same scripts that normally run on bootup to runlevel 3.
You could also delete all these shell scripts and replace them with your own code for configuring the system.
You have erroneously conflated rc and init, as others have pointed out.