Runlevels vs Targets rc0.d?
 

Hey so i just found out that init uses runlevels with rc0.d,rc1.d,rc2.d etc to control how the system starts up. My question is and im really wondering is that since init uses runlevels and systemd uses targets, does that mean that systemd also uses the rc0.d,rc1.d,rc2.d names then? Or does it use a different name?

Only by happenstance.

The goal was to provide an emulation, and that emulation has its flaws (the big one is that it runs in parallel with some of the other initializations - such that sometimes things are not ready when the rc3.d scripts need them).

Most systems use run level 3 for multi-user mode, and run level 4 for desktop GUI startup which includes most (if not all) of the same options run level 3 has. Run level 3 is associated with rc3.d, though the GUI target does not (well at least on Fedora it doesn't) correspond to rc4.d. Run level 1 is normally associated with single user mode, and that does NOT correspond to the state used by systemd (it is called single user mode, but has a lot more things started than a native run level 1 usually has, which is root mounted read only). Systemd single user mode has md initialized, root mounted, dbus running, udev running, .... and can be surprising to the administrator first meeting systemd.

At least on fedora there are specific runlevel[0123456].target entries, but these are not the same as the rcX.d entries. What happens here is that each service that USED to be in rcX.d is given a "run unit" for systemd, and those files (xxx.service) contain specifications to be run after init reaches the "runlevelX.target", then they run... to get them in order requires the files to indicate other dependencies to be run before/after/needs/requires some other target/service.

And while it is possible to generate a chart of the dependency network used by systemd ("systemd-analyze dot --order | dot -Tsvg > systemd-system.svg)... it is unreadable (so many lines everywhere, and rather large...).

So they have similar names but do different stuff.. init runlevel 1 does not do as much things as systemd's target 1, which i assume is systemd's parallel advantages, and is also why some people are sketchy on systemd.. So its my understanding that init is more customizable then, cause its alot harder or impossible to make a dependency chart for systemd.. I'll review this and i definitely need a sys admin book but thanks alot man this helped alot!

It is the resulting complexity that is a big problem. It is also why it took almost 5 years before the developers had a mostly working network. The original goal was to have it in Fedora 13.. then 14... 15 had it but it didn't work well. 16 I found actually usable, though it still hung on shutdown, and would screw up networks. 17 and 18 didn't improve anything. 19/20 I didn't try. 21 seems to work - though there have been complaints about failures when trying to add a user developed service (so very hard to know where in the dependency network it should go). People started putting everything in the rc-local.service, and when it didn't work right adding sleeps to make it wait... On most sysVinit based systems rc.local is not started until after all entries in the runlevel are completed.. but with systemd it only waits until the network says it is ready...and then runs it along with everything else. Things still might not be ready; such as DNS, remote services like databases are not ready, even DHCP might still be holding things up, LDAP not reachable...).

It does seem to be more reliable when it is a single user workstation, with a single network interface, at least 22 appears to be ok on my laptop. Of course, this is also the simplest environment.

You might try reading about systemd at:
http://www.freedesktop.org/wiki/Software/systemd/