7 deleted 1 character in body
source | link

So, to answer the question, it uses a combination of etc/init.d and /etc/rc?.d/etc/rc?.d each time each timesystemdsystemd` loads or reloads. In whacky ways.

So, to answer the question, it uses a combination of etc/init.d and/etc/rc?.deach timesystemd` loads or reloads. In whacky ways.

So, to answer the question, it uses a combination of etc/init.d and /etc/rc?.d each time systemd loads or reloads. In whacky ways.

6 DRY up warning
source | link

Also note if the init.d script does specify runlevels buta service is absent from all rc?.d dirs (a la chkconfig --del my_service or its equivalent systemctl disable my_service"disabled", or if chkconfig was never run on it) then the systemd-sysv-generator does not enable it, so it is left "disabled" And thenolder versions of systemd it seems to not show up in the lists if you runwon't show up in systemctl list-units --all etctypical lists.

Also if the init.d script does specify runlevels but is absent from all rc?.d dirs (a la chkconfig --del my_service or its equivalent systemctl disable my_service, or if chkconfig was never run on it) then the systemd-sysv-generator does not enable it, so it is left "disabled" And then it seems to not show up in the lists if you run systemctl list-units --all etc.

Also note if a service is "disabled", on older versions of systemd it won't show up in typical lists.

5 added 58 characters in body
source | link

Also weird: if there is no runlevel specified in the init.d file and it isn't yet symlinked in any /etc/rc?.d folder, then the daemon, get this, assumessystemd-sysv-generatoreems to assume you want it to be started in runlevel 4 and 5. and guess what
Plus, even if your default starting runlevel is 3, that's the same as 4 and 5. So basically it assumesseems to assume you want to start it, no matter what, despite it not being symlinked in anywhere.any rc?.d dirs.

Also if the init.d script doesdoes specify runlevels but is "disabled" aabsent from all rc?.d dirs (a la chkconfig --del my_service or its equivalent systemctl disable my_service (or, or if chkconfigchkconfig was never run on it) then the daemonsystemd-reloadsysv-generator will "leavedoes not enable it disabled" when, so it is run (leave it off). Andleft "disabled" And then it won'tseems to not show up at allin the lists if you run systemctl list-units --all etc.

So in general that book doesn't seem quite in thea right oder. The systemd-sysv-generator runs very early on in the boot phase, and sets up services (as specified above) and also enables them in the "run level equivalent" target if it deems they should be autorun. Then the boot proceeds, and starts up all services in the normal systemd order.

So, to finally answer yourthe question, it uses a combination of etc/init.d and/etc/rc?.deach timesystemd` loads or reloads. In whacky ways.

Also weird: if there is no runlevel specified in the init.d file and it isn't yet symlinked in any /etc/rc?.d folder, then the daemon, get this, assumes you want it to be started in runlevel 4 and 5. and guess what, even if your default starting runlevel is 3, that's the same as 4 and 5. So basically it assumes you want it no matter what, despite it not being symlinked in anywhere.

Also if the init.d script does specify runlevels but is "disabled" a la chkconfig --del my_service or its equivalent systemctl disable my_service (or if chkconfig was never run on it) then daemon-reload will "leave it disabled" when it is run (leave it off). And then it won't show up at all if you run systemctl list-units --all etc.

So in general that book doesn't seem quite in the right oder. The systemd-sysv-generator runs very early on in the boot phase, and sets up services (as specified above) and also enables them in the "run level equivalent" target if it deems they should be autorun. Then the boot proceeds, and starts up all services in the normal systemd order.

So, to finally answer your question, it uses a combination of etc/init.d and/etc/rc?.deach timesystemd` loads or reloads. In whacky ways.

Also weird: if there is no runlevel specified in the init.d file and it isn't yet symlinked in any /etc/rc?.d folder, then the systemd-sysv-generatoreems to assume you want it to be started in runlevel 4 and 5.
Plus, even if your default starting runlevel is 3, that's the same as 4 and 5. So basically it seems to assume you want to start it, no matter what, despite it not being symlinked in any rc?.d dirs.

Also if the init.d script does specify runlevels but is absent from all rc?.d dirs (a la chkconfig --del my_service or its equivalent systemctl disable my_service, or if chkconfig was never run on it) then the systemd-sysv-generator does not enable it, so it is left "disabled" And then it seems to not show up in the lists if you run systemctl list-units --all etc.

So in general that book doesn't seem quite in a right oder. The systemd-sysv-generator runs very early on in the boot phase, and sets up services (as specified above) and also enables them in the "run level equivalent" target if it deems they should be autorun. Then the boot proceeds, and starts up all services in the normal systemd order.

So, to answer the question, it uses a combination of etc/init.d and/etc/rc?.deach timesystemd` loads or reloads. In whacky ways.

4 cross link
source | link
3 added 38 characters in body
source | link
2 more weirdness
source | link
1
source | link