A simple introduction to systemd

2019独角兽企业重金招聘Python工程师标准>>>

Systemd Basics
--------------

Feature
1. compatible with SysV and LSB init scripts
2. provides aggressive parallelization
3. use socket and D-Bus activation for starting services
4. offers on-demand starting of daemons
5. Keep track of processes using Linux control groups
6. support snapshotting and restoring of system state
7. maintain mount and automount points
8. implement an elaborate transactional dependency-based service control logic

Main idea for parallelization of services in systemd
The socket-based service activation and the bus-based service activation
together enable us to start all daemons in parallel, without any further
synchronization. Activation also allows us to do lazy-loading of services: if a
service is rarely used, we can just load it the first time somebody accesses the
socket or bus name, instead of starting it during boot

Another main idea in systemd is getting rid of shell scripts. Shell scripts,
as we all know, are slow to execute and hard to oversee and control.

A good metric for measuring shell script infestation of the boot process is the
PID number of the first process you can start after the system is fully booted
up. Boot up, log in, open a terminal, and type echo $$.

Use Control Groups (aka "cgroups") to keep track of processes for babysitting purpose.

On top of that certain high-level controls can be very useful, such as setting
up read-only file system overlays based on read-only bind mounts. That way one
can run certain daemons so that all (or some) file systems appear read-only to
them, so that EROFS is returned on every write request.

Finally logging is an important part of executing services: ideally every bit of
output a service generates should be logged away. An init system should hence
provide logging to daemons it spawns right from the beginning, and connect
stdout and stderr to syslog or in some cases even /dev/kmsg which in many cases
makes a very useful replacement for syslog (embedded folks, listen up!),
especially in times where the kernel log buffer is configured ridiculously large
out-of-the-box.

systemd has a minimal transaction system which pulls in dependencies and resolves
conflicts.

We support reexecution of the init process itself at any time. The daemon state
is serialized before the reexecution and deserialized afterwards. That way we
provide a simple way to facilitate init system upgrades as well as handover from
an initrd daemon to the final daemon.

Starting the work of removing shell scripts from the boot process we have recoded
part of the basic system setup in C and moved it directly into systemd. Among
that is mounting of the API file systems (i.e. virtual file systems such as /proc,
/sys and /dev.) and setting of the host-name.

There's an interactive mode which asks for confirmation each time a process is
spawned by systemd. You may enable it by passing systemd.confirm_spawn=1 on the
kernel command line.

More importantly however, it is also our plan to experiment with systemd not
only for optimizing boot times, but also to make it the ideal session manager,
to replace (or possibly just augment) gnome-session, kdeinit and similar daemons.
The problem set of a session manager and an init system are very similar: quick
start-up is essential and babysitting processes the focus. Using the same code
for both uses hence suggests itself. Apple recognized that and does just that
with launchd. And so should we: socket and bus based activation and
parallelization is something session services and system services can benefit
from equally.

Question
1. How does systemd set hostname?
2. Bus activation?
3. autofs?
4. SysV compatability? [LSB header]

autofs & automount
------------------
autofs is a program for automatically mounting directories on an as-needed basis.
Auto-mounts are mounted only as they are accessed, and are unmounted after a
period of inactivity.


Upstart
-------
Upstart does not share code with sysvinit, and its functionality is a super-set
of it, and provides compatibility to some degree with the well known SysV init
scripts. It's main feature is its event-based approach: starting and stopping of
processes is bound to "events" happening in the system, where an "event" can be
a lot of different things, such as: a network interfaces becomes available or
some other software has been started.

Furthermore, the event logic turns around all dependencies, from the feet onto
their head. Instead of minimizing the amount of work (which is something that a
good init system should focus on), it actually maximizes the amount of work to
do during operations. Or in other words, instead of having a clear goal and only
doing the things it really needs to do to reach the goal, it does one step, and
then after finishing it, it does all steps that possibly could follow it.

Or to put it simpler: the fact that the user just started D-Bus is in no way an
indication that NetworkManager should be started too (but this is what Upstart
would do). It's right the other way round: when the user asks for NetworkManager,
that is definitely an indication that D-Bus should be started too (which is
certainly what most users would expect, right?).

systemd V.S. upstart
--------------------
On-demand logic v.s. Event-based logic

Systemd V.S. Sysvinit
---------------------
The central responsibility of an init system is to bring up userspace. And a
good init system does that fast. Unfortunately, the traditional SysV init system
was not particularly fast.

Right now, on boot-up a lot of time is spent idling to wait until all devices
that are listed in /etc/fstab show up in the device tree and are then fsck'ed,
mounted, quota checked (if enabled). Only after that is fully finished we go on
and boot the actual services.

References
----------
http://0pointer.de/blog/projects/systemd.html
https://help.ubuntu.com/community/Autofs
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html
http://freedesktop.org/wiki/Software/systemd/Optimizations
http://lwn.net/Articles/299483/
https://wiki.archlinux.org/index.php/Systemd
http://freedesktop.org/wiki/Software/systemd/
http://www.freedesktop.org/software/systemd/man/
http://0pointer.de/blog/projects/systemd-update.html
http://0pointer.de/blog/projects/systemd-update-2.html
http://0pointer.de/blog/projects/systemd-update-3.html
http://0pointer.de/blog/projects/why.html
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
http://www.freedesktop.org/wiki/Software/systemd
http://en.wikipedia.org/wiki/Systemd

转载于:https://my.oschina.net/u/158589/blog/111804