Difference between revisions of "Init vs systemd"

From CDOT Wiki
Jump to: navigation, search
Line 13: Line 13:
 
== The Old Way: init ==
 
== The Old Way: init ==
  
Upon computer boot-up, and after the Kernel process is started, it traditionally launched the '''init'''process (usually Process  ID #: 1). This important process manages (launches) other common services. In many ways, the init process is the "ancestor process" and any process that is currently running on the Unix/Linux system is either directly or indirectly related to the init process.
+
Upon computer boot-up, and after the Kernel process is started, it traditionally launched the '''init'''process (usually Process  ID #: 1). This important process manages (launches) other common services. The init process also has the ability to manage process (for example, respawing or "restarting" processes if they are terminated for some reason).
  
Traditionally, the init program would run default processes that were defined in "shell scripts" contained in appropriate run-level directory.
+
In many ways, the init process is the "ancestor process" and any process that is currently running on the Unix/Linux system is either directly or indirectly related to the init process.
  
== The Newer Way: systemd ==
+
Traditionally, the init program would run default processes that were defined in "shell scripts" contained in appropriate '''run-level''' directory. The run level is a defined state that the Unix/Linux system is currently in (for example, graphical-mode, text-based mode with networking, text-based mode without networking, etc).
 +
== Why Switch to systemd? ==
 +
 
 +
 
 +
Why switch to systemd when the concept of init and run levels seemed to work for 40 years! If it isn't broke, why try to fix it?
 +
 
 +
 
 +
Yes, the concept is very easy to understand. On the other hand, with modern operating systems, there is pressure to "evolve" into more efficent running operating systems.
 +
 
 +
 
 +
  
 
= systemd: Usage =
 
= systemd: Usage =

Revision as of 14:17, 6 February 2012

Overview

Definition of systemd

According to Lennart Poettering, the developper of systemd:

"systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting devices."


In Simpler Terms:

systemd is a more efficient method of controlling processes. It has the flexibility to start services in parallel, and have them communicate with each other, even if they are restarted (respawned). This is particularly useful for system administrators to temporarily service or update services without affecting the other dependent services.

The Old Way: init

Upon computer boot-up, and after the Kernel process is started, it traditionally launched the initprocess (usually Process ID #: 1). This important process manages (launches) other common services. The init process also has the ability to manage process (for example, respawing or "restarting" processes if they are terminated for some reason).

In many ways, the init process is the "ancestor process" and any process that is currently running on the Unix/Linux system is either directly or indirectly related to the init process.

Traditionally, the init program would run default processes that were defined in "shell scripts" contained in appropriate run-level directory. The run level is a defined state that the Unix/Linux system is currently in (for example, graphical-mode, text-based mode with networking, text-based mode without networking, etc).

Why Switch to systemd?

Why switch to systemd when the concept of init and run levels seemed to work for 40 years! If it isn't broke, why try to fix it?


Yes, the concept is very easy to understand. On the other hand, with modern operating systems, there is pressure to "evolve" into more efficent running operating systems.



systemd: Usage

General Concept

systdctrl

Additional Resources