systemd менеджер по системе и сервису (systemd system and service manager)
Концепции (Concepts)
systemd provides a dependency system between various entities
called "units" of 11 different types. Units encapsulate various
objects that are relevant for system boot-up and maintenance. The
majority of units are configured in unit configuration files,
whose syntax and basic set of options is described in
systemd.unit(5), however some are created automatically from
other configuration files, dynamically from system state or
programmatically at runtime. Units may be "active" (meaning
started, bound, plugged in, ..., depending on the unit type, see
below), or "inactive" (meaning stopped, unbound, unplugged, ...),
as well as in the process of being activated or deactivated, i.e.
between the two states (these states are called "activating",
"deactivating"). A special "failed" state is available as well,
which is very similar to "inactive" and is entered when the
service failed in some way (process returned error code on exit,
or crashed, an operation timed out, or after too many restarts).
If this state is entered, the cause will be logged, for later
reference. Note that the various unit types may have a number of
additional substates, which are mapped to the five generalized
unit states described here.
The following unit types are available:
1. Service units, which start and control daemons and the
processes they consist of. For details, see
systemd.service(5).
2. Socket units, which encapsulate local IPC or network sockets
in the system, useful for socket-based activation. For
details about socket units, see systemd.socket(5), for
details on socket-based activation and other forms of
activation, see daemon(7).
3. Target units are useful to group units, or provide well-known
synchronization points during boot-up, see systemd.target(5).
4. Device units expose kernel devices in systemd and may be used
to implement device-based activation. For details, see
systemd.device(5).
5. Mount units control mount points in the file system, for
details see systemd.mount(5).
6. Automount units provide automount capabilities, for on-demand
mounting of file systems as well as parallelized boot-up. See
systemd.automount(5).
7. Timer units are useful for triggering activation of other
units based on timers. You may find details in
systemd.timer(5).
8. Swap units are very similar to mount units and encapsulate
memory swap partitions or files of the operating system. They
are described in systemd.swap(5).
9. Path units may be used to activate other services when file
system objects change or are modified. See systemd.path(5).
10. Slice units may be used to group units which manage system
processes (such as service and scope units) in a hierarchical
tree for resource management purposes. See systemd.slice(5).
11. Scope units are similar to service units, but manage foreign
processes instead of starting them as well. See
systemd.scope(5).
Units are named as their configuration files. Some units have
special semantics. A detailed list is available in
systemd.special(7).
systemd knows various kinds of dependencies, including positive
and negative requirement dependencies (i.e. Requires= and
Conflicts=) as well as ordering dependencies (After= and
Before=). NB: ordering and requirement dependencies are
orthogonal. If only a requirement dependency exists between two
units (e.g. foo.service requires bar.service), but no ordering
dependency (e.g. foo.service after bar.service) and both are
requested to start, they will be started in parallel. It is a
common pattern that both requirement and ordering dependencies
are placed between two units. Also note that the majority of
dependencies are implicitly created and maintained by systemd. In
most cases, it should be unnecessary to declare additional
dependencies manually, however it is possible to do this.
Application programs and units (via dependencies) may request
state changes of units. In systemd, these requests are
encapsulated as 'jobs' and maintained in a job queue. Jobs may
succeed or can fail, their execution is ordered based on the
ordering dependencies of the units they have been scheduled for.
On boot systemd activates the target unit default.target whose
job is to activate on-boot services and other on-boot units by
pulling them in via dependencies. Usually, the unit name is just
an alias (symlink) for either graphical.target (for
fully-featured boots into the UI) or multi-user.target (for
limited console-only boots for use in embedded or server
environments, or similar; a subset of graphical.target). However,
it is at the discretion of the administrator to configure it as
an alias to any other target unit. See systemd.special(7) for
details about these target units.
systemd only keeps a minimal set of units loaded into memory.
Specifically, the only units that are kept loaded into memory are
those for which at least one of the following conditions is true:
1. It is in an active, activating, deactivating or failed state
(i.e. in any unit state except for "inactive")
2. It has a job queued for it
3. It is a dependency of at least one other unit that is loaded
into memory
4. It has some form of resource still allocated (e.g. a service
unit that is inactive but for which a process is still
lingering that ignored the request to be terminated)
5. It has been pinned into memory programmatically by a D-Bus
call
systemd will automatically and implicitly load units from disk —
if they are not loaded yet — as soon as operations are requested
for them. Thus, in many respects, the fact whether a unit is
loaded or not is invisible to clients. Use systemctl list-units
--all to comprehensively list all units currently loaded. Any
unit for which none of the conditions above applies is promptly
unloaded. Note that when a unit is unloaded from memory its
accounting data is flushed out too. However, this data is
generally not lost, as a journal log record is generated
declaring the consumed resources whenever a unit shuts down.
Processes systemd spawns are placed in individual Linux control
groups named after the unit which they belong to in the private
systemd hierarchy. (see cgroups.txtps xawf -eo pid,user,cgroup,args is
particularly useful to list all processes and the systemd units
they belong to.).
systemd is compatible with the SysV init system to a large
degree: SysV init scripts are supported and simply read as an
alternative (though limited) configuration file format. The SysV
/dev/initctl interface is provided, and compatibility
implementations of the various SysV client tools are available.
In addition to that, various established Unix functionality such
as /etc/fstab or the utmp database are supported.
systemd has a minimal transaction system: if a unit is requested
to start up or shut down it will add it and all its dependencies
to a temporary transaction. Then, it will verify if the
transaction is consistent (i.e. whether the ordering of all units
is cycle-free). If it is not, systemd will try to fix it up, and
removes non-essential jobs from the transaction that might remove
the loop. Also, systemd tries to suppress non-essential jobs in
the transaction that would stop a running service. Finally it is
checked whether the jobs of the transaction contradict jobs that
have already been queued, and optionally the transaction is
aborted then. If all worked out and the transaction is consistent
and minimized in its impact it is merged with all already
outstanding jobs and added to the run queue. Effectively this
means that before executing a requested operation, systemd will
verify that it makes sense, fixing it if possible, and only
failing if it really cannot work.
Note that transactions are generated independently of a unit's
state at runtime, hence, for example, if a start job is requested
on an already started unit, it will still generate a transaction
and wake up any inactive dependencies (and cause propagation of
other jobs as per the defined relationships). This is because the
enqueued job is at the time of execution compared to the target
unit's state and is marked successful and complete when both
satisfy. However, this job also pulls in other dependencies due
to the defined relationships and thus leads to, in our example,
start jobs for any of those inactive units getting queued as
well.
systemd contains native implementations of various tasks that
need to be executed as part of the boot process. For example, it
sets the hostname or configures the loopback network device. It
also sets up and mounts various API file systems, such as /sys/
or /proc/.
For more information about the concepts and ideas behind systemd,
please refer to the Original Design Document
Note that some but not all interfaces provided by systemd are
covered by the Interface Portability and Stability Promise
Units may be generated dynamically at boot and system manager
reload time, for example based on other configuration files or
parameters passed on the kernel command line. For details, see
systemd.generator(7).
The D-Bus API of systemd is described in
org.freedesktop.systemd1(5) and org.freedesktop.LogControl1(5).
Systems which invoke systemd in a container or initrd environment
should implement the Container Interfaceinitrd
Interface
