4

I started disabling some services from systemd to speed up the boot time, but I noticed that many services are also in the old init (which runs). There are quite a few things that start in rc.d (or at least my script started when I placed it there originally).

My question is, why are some services in both places, and do I also have to remove them from rc.d ?

  • A minor clarification: It's not a matter of "systemd vs init". Systemd is an init implementation, just as the SysV style init previously used was an implementation. Both of them satisfy the requirements of the role with regard to the relationship to the OS kernel and responsibilities in userland. I've edited your title to prevent further confusion ;) – goldilocks Jan 21 '18 at 14:46
5

It's still systemd that handles the old-style init scripts, using systemd-sysv-generator:

systemd-sysv-generator is a generator that creates wrapper .service units for SysV init[1] scripts in /etc/init.d/* at boot and when configuration of the system manager is reloaded. This will allow systemd(1) to support them similarly to native units.

LSB headers[2] in SysV init scripts are interpreted, and the ordering specified in the header is turned into dependencies between the generated unit and other units. The LSB facilities "$remote_fs", "$network", "$named", "$portmap", "$time" are supported and will be turned into dependencies on specific native systemd targets. See systemd.special(5) for more details.

SysV runlevels have corresponding systemd targets (runlevel X.target). The wrapper unit that is generated will be wanted by those targets which correspond to runlevels for which the script is enabled.

systemd does not support SysV scripts as part of early boot, so all wrapper units are ordered after basic.target.

Essentially, the documentation states that systemd generates unit files at startup for the services in rc.d, and uses the LSB headers to determine when the services should run.

In Jessie and Stretch, LSB headers have been added to all old-style init scripts in rc.d, so these can continue to work despite the switch to systemd. As for why this is the case: this answer suggests that the plan was to have sysvinit as a fallback in Debian, and most likely for compatibility reasons also.

That said, there are some contradictions between the documentation, and what users have observed to actually be true. This answer on Unix & Linux claims that the headers are not required at all for systemd to convert them, which would explain why systemd still used your script, despite you probably not writing a perfectly LSB-compliant header.

You will need to remove the init scripts as you would with the old init daemon in order to stop these services from running too. See also: disable init.d script in systemd on Unix & Linux.

  • Actually I wrote a header for it, copied it from somewhere else :) So if I do a systemctl list-unit-files, only what shows as enabled is loaded at boot? – Radu Jan 21 '18 at 13:37
  • It should do, @Radu, yes; that'll be a mix of systemd and converted SysVInit services. – Aurora0001 Jan 21 '18 at 13:40
  • Or do I have to disable stuff from init.d too, since systemctl disable won't disable the init.d stuff also? – Radu Jan 21 '18 at 13:41
  • You can disable the init.d services the old-fashioned way, or use systemd mask as described here. Either should work. – Aurora0001 Jan 21 '18 at 13:42
  • 1
    Thanks, I will open a new question, because I did a systemd-analyze blame and I don't like what I am seeing :D – Radu Jan 21 '18 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.