systemd is the system and service manager used by most major Linux distributions. Its own manual page defines it plainly: “systemd is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services.” In that role it is the first userspace program the kernel starts, the ancestor of every other process, and the component responsible for getting the rest of the system into a working state and keeping it there.
The project was announced by Lennart Poettering on April 30, 2010, in a blog post titled “Rethinking PID 1.” There he set out his case against the existing approaches, SysV init and Upstart, and described the design he was experimenting with. Two ideas were central. The first was socket-based activation: “create the listening sockets before we actually start the daemon, and then just pass the socket during exec() to it,” which lets services start in parallel rather than in a slow serial chain. The second was explicit dependency management through “positive and negative requirement dependency,” the Requires, Wants, and Conflicts relations that let systemd order startup without the manual event choreography Poettering criticized in event-based systems. He summed up the mood of the effort in one line: “We are experimenting with a new init system and it is fun.”
systemd organizes the system into entities called units. The manual page describes “a dependency system between various entities called ‘units’ of 11 different types,” including service units for daemons, socket units for the listening sockets, target units that group other units (replacing the old runlevels), and timer units that schedule jobs as an alternative to cron. This declarative, file-based model, where an administrator describes what should be running and how units relate, rather than writing imperative shell scripts, was the practical change most users felt.
Around the core manager grew a suite of related components: journald for structured, binary system logging; logind for managing user sessions; networkd and resolved for networking; and many others. This breadth is exactly what made systemd controversial. Critics argued it absorbed too many responsibilities into one project and broke the Unix tradition of small, separable tools, while supporters pointed to faster boots, consistent service management, and a single coherent model. The debate was sharp enough to fork at least one distribution.
The argument was ultimately settled by adoption. Over the first half of the 2010s, the large Linux distributions, including Debian, Fedora, Red Hat, Ubuntu, Arch, and SUSE, made systemd their default init system. Whatever the merits of the dispute, the result is that for a typical Linux machine today, PID 1 is systemd, and the unit file is how services are defined.
systemd is best understood as both a piece of software and a turning point in Linux’s history: the moment the loose collection of init scripts and helper daemons that had managed Unix systems for decades was replaced, across nearly the whole ecosystem, by a single integrated manager.