System Services and Startup

Every time you press the power button on a Linux computer, a precise sequence of events begins. This is the boot process. The first thing that runs is the BIOS or UEFI (Basic Input/Output System or Unified Extensible Firmware Interface) — tiny firmware stored on the motherboard. It performs a Power-On Self-Test (POST) to check that hardware like RAM and hard drives are working. Then it looks for a bootable device (the hard disk, USB drive, or network) and hands control to the bootloader.

The bootloader, most commonly GRUB (Grand Unified Bootloader), is the first piece of real software to run. Its job is to load the Linux kernel into memory. The kernel is the core of the operating system — it manages hardware, memory, and processes. GRUB presents a menu if you have multiple kernels installed, then uncompresses the kernel and starts it.

Once the kernel is running, it initialises all the hardware it can detect using built-in drivers. It then mounts the root filesystem — that is, it makes the main filesystem (like /) accessible. At this point, the kernel starts the first user-space process: the init system. On modern Linux distributions, this is almost always systemd. systemd is process number 1 (PID 1). It never dies; if it does, the kernel panics and the system crashes.

systemd takes over from here. It reads its configuration files to determine which services to start and in what order. These services are defined in unit files. Each unit file describes a service (like a web server or database), a socket, a device, a mount point, or another resource. Services have dependencies: for example, a database service might require the network to be up first. systemd sorts these dependencies into a dependency tree and starts everything in parallel where possible, aiming to reach a target state.

A target in systemd is a group of services that bring the system to a certain operational level — similar to the old concept of runlevels. For example, graphical.target boots the system into a full desktop environment, while multi-user.target boots into a text-mode multi-user environment without a graphical interface. The default target is usually set to graphical.target on desktops or multi-user.target on servers.

Once the target is reached, the system is fully operational. But managing services continues day-to-day. You can check the status of a service with 'systemctl status servicename'. You can start ('systemctl start'), stop ('systemctl stop'), restart ('systemctl restart'), enable (make it start at boot), or disable (prevent it from starting at boot) services. The 'enable' command creates a symbolic link in the filesystem that tells systemd to start the service at boot. The 'disable' command removes that link.

If something goes wrong, you can check the logs with 'journalctl -u servicename'. The journal is systemd's logging system, which collects all system messages in one place. You can also mask a service, which makes it impossible to start even manually — useful for services you never want to run.

The boot process and service management are intimately connected. Understanding systemd's unit files, targets, and dependency resolution is essential for passing XK0-006. The exam expects you to know how to edit unit files, override settings with drop-in snippets, and troubleshoot services that fail to start because of missing dependencies or configuration errors.

Imagine you are a junior Linux administrator at a small e-commerce company. The company runs its website on a single Linux server. One Monday morning, customers start reporting that the site is down. You need to troubleshoot what happened.

First, you SSH into the server. You run 'systemctl status httpd' (or 'nginx' depending on the web server). The output shows 'inactive (dead)' — the web server is not running. You check the logs with 'journalctl -u httpd' and see an error: 'bind to port 80 failed: Address already in use'. This suggests another process is occupying port 80. You run 'netstat -tlnp' and find that Apache was started twice, but the real issue is a misconfigured virtual host file.

You stop the duplicate process, edit the configuration, and restart the service using 'systemctl restart httpd'. Then you check that the service is 'active (running)' and that the site loads. You also want to ensure this does not happen on next reboot. You run 'systemctl is-enabled httpd' and it returns 'enabled', so it will start automatically at boot. But you remember that the database server (MariaDB) failed last week because the filesystem was full. You check disk space with 'df -h', clear old logs, and verify that MariaDB is also enabled and healthy.

You might also need to adjust the boot target. If this server is headless (no monitor), running 'graphical.target' wastes resources. You can check the default target with 'systemctl get-default' and change it to 'multi-user.target' with 'systemctl set-default multi-user.target' and reboot.

Another common task is creating custom service unit files so your own script or application starts at boot. For example, if the company uses a custom inventory management app, you write a unit file, drop it in '/etc/systemd/system/', run 'systemctl daemon-reload', then enable and start it.

The exam will test you on exactly these commands and scenarios. In real life, you also encounter scenarios where a service depends on a network mount. If the network mount fails, the service hangs. You learn to add 'After' and 'Requires' directives in unit files to prevent that. These are the practical skills that make you a competent administrator.