Exercise 2: Why System V init Would Delay cron Unnecessarily — Possible Solution ==================================================================== Explanation: Per the chapter's own example, System V init's numbered scripts run strictly one after another, in whatever order they happen to be numbered -- S01networking, then S02syslog, then S03cron, then S04apache2. Because this is a purely SEQUENTIAL model, S03cron cannot begin running until S02syslog has fully finished, and S02syslog can't begin until S01networking has fully finished, regardless of whether cron actually needs anything from syslog or networking to function at all. Cron genuinely doesn't depend on networking or syslog being ready first -- it's just been assigned a script number that happens to place it after them -- but System V init's own sequential model has no way to express "these two things are unrelated, run them independently." Cron simply has to wait its turn in the numbered queue, wasting real boot time on a dependency that doesn't actually exist. systemd avoids this specifically because it expresses dependencies EXPLICITLY rather than through numbering, per the chapter's own description. apache2.service genuinely does depend on networking.service (it needs the network to actually serve requests), so systemd correctly waits for networking before starting apache2. But cron.service has no such explicit dependency declared anywhere, so systemd is free to start it in parallel, as soon as ITS OWN actual dependencies (if any) are satisfied -- never forced to wait behind apache2 or syslog just because of where it happened to land in some arbitrary sequence. WHY THIS WORKS AS AN ANSWER ------------------------------ This traces the specific mechanical reason (purely sequential numbering with no way to express "unrelated") that forces System V init to delay cron unnecessarily, then contrasts it with systemd's explicit-dependency model using the chapter's own named services rather than a generic restatement of "systemd is parallel."