Linux boot simulator: systemd step by step

Each line describes one unit: its name, how long it takes to start, its type and its dependencies, much as the [Unit] and [Service] sections of a unit file would. The simulator pulls in every unit the boot target needs, starts each as soon as the units it is ordered after are up, and draws the result. Pick a unit to fail to see what else it takes down, and set the firmware, loader, kernel and initrd times to complete the systemd-analyze time line.

When a Linux machine powers on, the firmware (UEFI on current hardware) initialises the hardware and runs a boot loader from disk, such as GRUB or systemd-boot. The boot loader loads the kernel and an initramfs, a small archive with the drivers and tools needed to find and mount the real root file system, which may be encrypted, on LVM or on the network. The kernel unpacks the initramfs and runs its init; once the root file system is mounted, control passes to systemd on the real root as process 1, which starts everything else.

systemd-analyze time reports these phases separately when the firmware and boot loader pass on their timings, as UEFI with systemd-boot does: in the server example, Startup finished in 3.2s (firmware) + 0.9s (loader) + 1.3s (kernel) + 2.1s (initrd) + 6.35s (userspace) = 13.85s. The last part, user space, is what the unit graph decides, and usually the part you can change.

systemd manages units: services, mounts, sockets, devices and targets, which are named groups such as multi-user.target that stand for a state of the system. Booting means starting the default target, and systemd builds a transaction of every unit it pulls in. Two kinds of setting shape it, and they are independent:

• Requirement: Wants= pulls a unit in and does not care if it fails; Requires= pulls it in and makes this unit fail too if it fails and they are ordered. WantedBy=multi-user.target in an [Install] section adds a Wants= to the target when the unit is enabled.
• Ordering: After= and Before= only say which starts first, for units that are both in the transaction.

Units with no ordering between them start in parallel, which is where systemd gets its speed. Targets have one extra rule: a target is automatically ordered after the units it wants or requires, unless an ordering between them is already set, so reaching multi-user.target means everything it pulled in has started. The server example pulls in 20 units.

systemd-analyze blame lists units by how long they took to start. It is easy to misread: units start in parallel, so the longest one may not have delayed anything. systemd-analyze critical-chain answers the better question, what the target was actually waiting for. It starts at the target and, at each level, follows the dependency that finished last. In the server example:

multi-user.target @6.35s
└─app.service @6.35s
  └─docker.service @4.05s +2.3s
    └─network-online.target @4.05s
      └─systemd-networkd-wait-online.service @550ms +3.5s
        └─systemd-networkd.service @300ms +250ms
          └─systemd-udevd.service @0ms +300ms

Read it from the bottom: udevd, then networkd, then 3.5 s in systemd-networkd-wait-online.service, then Docker, then the app. The 1.4 s file system check near the top of blame ran in parallel and is not on the chain, so making it faster would not shorten the boot.

network.target only means the network management stack has been started; network-online.target means a wait-online service has decided the network is configured, which can take seconds and depends on DHCP, link negotiation and the definition of "online". Anything ordered after network-online.target waits for it. In the example, Docker and nginx do; removing those dependencies cuts user space from 6.35s to 5.2s, and the critical chain moves to the file system check and containerd. Services that only need to listen on a socket can usually order after network.target, or bind to any address, and leave network-online.target to things that genuinely need a remote host at start-up.

After= waits until a unit has "started", and what that means depends on the service's Type=. For simple, the default, systemd counts the service as started as soon as it forks the process; for exec, once the program has been executed. Neither waits for the program to be ready. oneshot waits for the process to exit, forking for the parent to exit after starting a daemon, and notify for the service to send READY=1 through sd_notify. In the Type=simple trap example the API is ordered after a database that needs 4 s to be ready, but the database is Type=simple, so the API starts at once and the target is reached after 300ms, long before the database can take connections. Making the database Type=notify fixes the order.

When a unit fails, units that Requires= it and are ordered after it are not started and get "dependency failed". In the A failing service example, Docker fails and app.service follows; the target is still reached, because it only wants those services. Making containerd.service fail instead stops nothing else, since Docker only Wants= it. Some units react to failure: local-fs.target has OnFailure=emergency.target, which is why a failed mount drops the machine into emergency mode rather than continuing.

An ordering cycle, such as a after b, b after c and c after a, has no valid order. systemd detects it when building the transaction, logs "Found ordering cycle" with the units involved, and deletes one of the jobs to break it, so a unit can silently not start until someone reads the journal.

Start-up times are fixed numbers you choose, and a unit starts as soon as everything it is ordered after has started; real systems also wait on devices, disks and CPU. Services' default dependencies (on sysinit.target and basic.target) are not added automatically, so the examples write them out. Conflicts=, OnFailure=, socket and path activation and job modes are not modelled. The output follows the format of systemd-analyze, with times measured from the start of user space.