202.1 Customizing system startup

Introduction

Startup configuration determines which services run, in what order, and under which conditions. LPIC-2 expects a strong understanding of systemd as well as the older SysV init model.

What you should be able to do after this lesson:

• Inspect, start, stop, enable, and mask systemd units.
• Read dependencies and the default target.
• Create safe local unit overrides.
• Map SysV runlevels to systemd targets.
• Diagnose a service that delays or fails during boot.

Big Idea: Activation, Enablement, and Ordering Are Separate

A service can be running now but disabled for the next boot, enabled but currently stopped, or correctly ordered but never requested by another unit. Keep these questions separate:

1. Is the unit active now?
2. Is it enabled for future boots?
3. Which unit requests it?
4. What must start before or after it?

Most systemd mistakes come from treating those four relationships as one setting.

systemd Units and State

systemctl status sshd.service
systemctl start sshd.service
systemctl stop sshd.service
systemctl restart sshd.service
systemctl reload sshd.service

Runtime state and boot state are different:

• start affects the current boot
• enable creates boot-time relationships
• disable removes those relationships
• mask prevents all normal starts by linking the unit to /dev/null

systemctl enable --now sshd.service
systemctl is-enabled sshd.service
systemctl mask example.service

Unit File Locations and Precedence

Common locations are:

• /usr/lib/systemd/system/ or /lib/systemd/system/ for package units
• /etc/systemd/system/ for administrator configuration
• /run/systemd/system/ for runtime units

Administrator files under /etc take precedence. Do not edit a packaged unit directly when an override can express the change.

systemctl cat example.service
systemctl edit example.service
systemctl daemon-reload

systemctl edit creates a drop-in override. systemd-delta shows local differences from vendor defaults.

Targets and Dependencies

Targets group units and replace much of the role of SysV runlevels.

systemctl get-default
systemctl set-default multi-user.target
systemctl isolate rescue.target
systemctl list-dependencies multi-user.target

Common mappings:

• runlevel 3 resembles multi-user.target
• runlevel 5 resembles graphical.target
• runlevel 1 resembles rescue.target

isolate stops units not required by the target, so use it carefully on remote systems.

Unit Relationships

Important directives include:

• Requires= for a strong requirement
• Wants= for a weaker relationship
• After= and Before= for ordering only
• WantedBy= in the install section for enablement

Ordering does not automatically create a dependency. A unit can specify After=network.target without requiring that target.

Other useful relationships include Conflicts= for mutually exclusive units and PartOf= when stop or restart operations should propagate from another unit. Conditions such as ConditionPathExists= can skip a unit without treating the result as a failure.

SysV Init

Traditional SysV systems use scripts under /etc/init.d/ and runlevel links under directories such as /etc/rc3.d/.

The Linux Standard Base (LSB) defined conventions for init-script metadata and behavior so service-management tools could understand dependencies and runlevel intent across distributions. Modern systemd units use a different native format, but LPIC-2 expects awareness of the LSB role in SysV init environments.

service ssh status
/etc/init.d/ssh restart
runlevel
telinit 3

Tools such as update-rc.d and chkconfig manage startup links on different distributions. /etc/inittab historically defines init behavior and the default runlevel.

Diagnose Startup

systemctl --failed
systemd-analyze blame
systemd-analyze critical-chain
journalctl -b -u <unit>

Check both why a unit failed and which dependency requested it. Do not assume the slowest listed unit alone caused the full boot delay; parallel startup affects timing.

Guided Practice: Inspect and Override a Unit

Choose a noncritical service on a lab machine:

systemctl status <unit>
systemctl is-active <unit>
systemctl is-enabled <unit>
systemctl cat <unit>
systemctl show <unit> -p Wants -p Requires -p After -p Before

Create a drop-in with systemctl edit <unit> and add a harmless environment variable:

[Service]
Environment=LPIC_LAB=1

Then run:

sudo systemctl daemon-reload
systemctl cat <unit>
systemd-delta

If restarting the selected service is safe, verify the effective environment through systemctl show <unit> -p Environment. Remove the drop-in after the exercise and reload the manager again.

Troubleshooting Scenario

A service is enabled but does not start successfully during boot. Its unit contains After=network.target, yet its log shows that the required remote endpoint is unavailable.

After= only controls ordering and network.target does not guarantee usable network connectivity. Determine whether the service requires network-online.target, which wait-online implementation supplies it, and whether the application should retry independently. Adding Requires=network.target alone would not prove the network is configured.

Exam Focus

• Know the precedence of /etc/systemd, /run/systemd, and /usr/lib/systemd.
• Distinguish start, enable, disable, mask, and isolate.
• Map SysV runlevels to common systemd targets.
• Recognize /etc/inittab, /etc/init.d/, chkconfig, update-rc.d, init, and telinit.

Recap

• Current activation and boot enablement are separate concepts.
• Local systemd changes belong in overrides under /etc.
• Dependency and ordering directives solve different problems.
• Know the corresponding SysV commands and runlevel model.