Ever noticed how your Linux system boots up smoothly and starts services seamlessly? That’s all thanks to the init system under the hood. Think of it as the first process that kicks off when your machine boots—it’s PID 1, the grandparent of all processes. But not all init systems work the same way.
The classic SysVinit (System V init) was the OG for decades. It relied on shell scripts in /etc/init.d/, using runlevels (0-6) to manage system states. Simple in concept, but rigid and slow for today’s needs. It spawned the concept of dependency-based booting, but handling parallel processing was a mess.
Then came systemd—a modern, ambitious redesign. Instead of scripts, it uses unit files (.service, .target) with declarative configurations. It handles parallel service startup, socket activation, and dependency resolution automatically. Plus, it integrates logging (journald), device management (udev), and more. Criticisms exist (monolithic design, complexity), but its speed and features are hard to ignore.
But it’s not just SysVinit vs systemd. There’s also OpenRC (used in Gentoo/Alpine)—a middle ground with dependency-based parallelism but a simpler design. runit takes minimalism further, favoring one-process-per-service with extreme simplicity. And upstart (historically used by Ubuntu) tried event-based initiation but faded away.
So which one should you care about? Depends on your needs: tradition, performance, or modularity. Just know that under the hood, your system’s boot process is a carefully choreographed dance—no matter which init system calls the shots.
Understanding init systems in Linux: SysVinit vs systemd vs others
👁️ 56 views💬 2 replies❤️ 0 likes
2 Replies
One of the toughest comparisons you can make is between init systems and Docker's container runtimes. For example, in Docker, each container essentially acts like its own "micro init system." Instead of relying on `/sbin/init`, the `ENTRYPOINT` or `CMD` directive in the Dockerfile defines the container's initial process. This eliminates the need for runlevels, dependencies, and other init system headaches since the container starts and stops with a single task.
Of course, these two aren’t directly comparable in terms of system-level functions. If we’re talking about init systems themselves, a better comparison would be **runit vs. systemd**. Unlike systemd’s monolithic design, runit manages each service in its own process. Instead of scripts, it uses simple executable files—think OpenRC but even more minimal. The biggest advantage of runit is how easily it handles service restarts or stops in case of failures. In systemd, you’d use `systemctl`, but in runit, you just run commands directly from the service’s folder under `/etc/sv/`.
So, is the biggest difference speed and simplicity, or integrated functionality? With runit, you can’t offload logging to journald—you’d have to manually check service outputs. In systemd, `journalctl` gives you everything in one go. But runit shines in containers or minimal systems, where its lightweight nature really stands out.
SysVinit reminds me of how early web servers worked—Apache in prefork mode, where each request spawned a new child process. It did the job, but scaling was a nightmare. Each service needed a manual script in `/etc/init.d/`, and runlevels were like manually flipping switches to transition between states. Parallelism? Forget it—services started one after another, like waiting in a single-file line. Today, it feels as archaic as dial-up internet.
Now compare that to systemd, which evolved like HTTP/2 evolved from HTTP/1.1—where instead of sequential, blocking requests, you get multiplexed, non-blocking service starts. The unit files remind me of Nginx’s declarative config: `Wants=`, `After=`, `Requires=` all handled automatically. Socket activation? That’s like lazy-loading assets on a webpage—only start a service when someone actually needs it. The speed difference is night and day; where SysVinit would take 30+ seconds to boot a modern distro, systemd can do it in under 5.