Inhaltsverzeichnis
Als Systemadministrator sollten Sie grob wissen, wie das Debian-System gestartet und konfiguriert wird. Obwohl die genauen Details in den Quelldateien der installierten Pakete und deren Dokumentation zu finden sind, ist dies für die meisten von uns ein bisschen viel.
Ich habe mein bestes gegeben, um einen schnellen Überblick über die wichtigsten Themen des Debian-Systems und dessen Konfiguration als Referenz für Sie bereitzustellen, basierend auf aktuellem und früherem Wissen von mir und anderen. Da das Debian-System sich ständig verändert, könnte sich die Situation teilweise verändert haben. Bevor Sie irgendwelche Änderungen an dem System vornehmen, sollten Sie die aktuellste Dokumentation der jeweiligen Pakete zu Rate ziehen.
![]() |
Tipp |
---|---|
bootup(7)
describes the system bootup process based on |
![]() |
Tipp |
---|---|
boot(7) describes the system bootup process based on UNIX System V Release 4. (Older Debian) |
Das Computer-System durchläuft verschiedene Phasen des Bootstrap-Prozesses vom Einschalten bis zur Bereitstellung des funktionalen Betriebssystems an den Benutzer.
Der Einfachheit halber beschränke ich meine Betrachtung auf die weit verbreitete PC-Plattform mit einer Standardinstallation.
Der typische Bootstrap-Prozess ist wie eine 4-stufige Rakete. Jede Stufe übergibt die Systemkontrolle an die jeweils nachfolgende Stufe:
Natürlich können diese unterschiedlich konfiguriert werden. Wenn Sie zum Beispiel Ihren eigenen Kernel kompilieren, werden Sie unter Umständen den Schritt mit dem Mini-Debian-System überspringen. Gehen Sie daher nicht davon aus, dass dies alles in Ihrem Fall zutrifft, solange Sie es nicht selbst überprüft haben.
![]() |
Anmerkung |
---|---|
Bei ungewöhnlichen Computer-Plattformen wie dem SUN- oder dem Macintosh-System könnten das BIOS im ROM und die Partitionen auf der Festplatte sich stark von dem hier beschriebenen unterscheiden (Abschnitt 9.5.2, „Konfiguration der Plattenpartitionen“). Bitte suchen Sie in solch einem Fall an anderer Stelle nach Plattform-spezifischer Dokumentation. |
Das BIOS ist die erste Stufe des Boot-Prozesses und wird durch das Einschalten des Rechners aufgerufen. Es liegt im Nur-Lese-Speicher (read only memory/ROM) und wird von einer speziellen Speicheradresse ausgeführt, auf die die CPU durch den Einschaltvorgang verwiesen wird.
Das BIOS führt die grundsätzliche Initialisierung der Hardware durch (POST: power on self test / Selbsttest nach dem Einschalten) und übergibt die Systemkontrolle an die nächste Stufe. Das BIOS wird üblicherweise mit der Hardware geliefert.
Im BIOS-Startbildschirm wird für gewöhnlich angezeigt, welche Taste(n) Sie drücken müssen, um das BIOS-Setup zu erreichen, in dem das Verhalten des BIOS konfiguriert werden kann. Typisch hierfür sind F1, F2, F10, Esc, Einfg und Entf. Wenn Ihr BIOS-Startbildschirm durch eine hübsche grafische Anzeige versteckt wird, müssen Sie eventuell eine oder mehrere Tasten wie z.B. Esc drücken, um diese Grafik auszublenden. Die hierzu benötigten Tasten sind je nach Hardware sehr unterschiedlich.
Die Hardware und die Reihenfolge des Codes, der durch das BIOS gestartet wird, kann über das BIOS-Setup ausgewählt werden. Typischerweise werden die ersten paar Sektoren des ersten gefundenen, vorgewählten Gerätes (Festplatte, Diskette, CD-ROM, …) in den Speicher geladen und dieser initiale Code wird dann ausgeführt. Das kann folgendes sein:
ein Bootloader-Code;
der Kernel-Code eines Ursprungs-Betriebssystems wie z.B. FreeDOS;
der Kernel-Code des Ziel-Betriebssystems, falls er in diesen kleinen Speicherbereich passt.
Gewöhnlich wird das System von der angegebenen Partition der primären Festplatte gestartet. Die ersten zwei Sektoren der Festplatte enthalten auf normalen PC-Systemen den Master Boot Record (MBR). Die Partitionsinformationen inklusive der Boot-Auswahl sind am Ende des MBR gespeichert. Der in der ersten Stufe vom BIOS ausgeführte Bootloader-Code liegt im Rest des MBR.
Der Bootloader ist die zweite Stufe des Boot-Prozesses und wird durch das BIOS gestartet. Er lädt das System-Kernel-Image und das initrd-Image in den Speicher und übergibt diesen die Kontrolle. Das initrd-Image ist ein Abbild des Wurzeldateisystems und seine Unterstützung hängt von dem verwendeten Bootloader ab.
Das Debian-System nutzt normalerweise den Linux-Kernel als Standard-System-Kernel. Das initrd-Image des aktuellen 2.6/3.x-Linux-Kernels ist technisch gesehen ein initramfs-Image (initial RAM filesystem). Das initramfs-Image ist ein mit gzip komprimiertes cpio-Archiv der Dateien im Wurzeldateisystem.
![]() |
Warnung |
---|---|
Obiges gilt nicht mehr für das neue Multi-Segment-initramfs. Lesen Sie dazu Bug #790100. |
Eine Standardinstallation des Debian-Systems auf der PC-Plattform legt den ersten Teil des GRUB-Bootloaders (stage 1) im MBR ab. Es sind allerdings viele weitere Bootloader und Konfigurationsoptionen verfügbar.
Tabelle 3.1. Liste der Bootloader
Paket | Popcon | Größe | initrd | Bootloader | Beschreibung |
---|---|---|---|---|---|
grub-legacy | V:0, I:2 | 710 | Unterstützt | GRUB Legacy | Intelligenter Bootloader, der Festplattenpartitionen und Dateisysteme wie vfat, ext3 … unterstützt. |
grub-pc | V:29, I:849 | 584 | Unterstützt | GRUB 2 | Intelligenter Bootloader, der Festplattenpartitionen und Dateisysteme wie vfat, ext4 … unterstützt. (Debian-Standard) |
grub-rescue-pc | V:0, I:1 | 6294 | Unterstützt | GRUB 2 | Dies ist das boot-fähige Rettungs-Image von GRUB 2 (CD und Diskette) (PC/BIOS-Version). |
lilo | V:0, I:3 | 693 | Unterstützt | Lilo | Beruht auf den Sektorbereichen der Daten auf der Festplatte (alt). |
syslinux | V:5, I:59 | 299 | Unterstützt | Isolinux | Unterstützt das ISO9660-Dateisystem. Dies wird von Boot-CDs verwendet. |
syslinux | V:5, I:59 | 299 | Unterstützt | Syslinux | Unterstützt das MSDOS-Dateisystem FAT. Dies wird von Boot-Disketten verwendet. |
loadlin | V:0, I:1 | 84 | Unterstützt | Loadlin | Das gewünschte Betriebssystem wird aus dem laufenden FreeDOS-/MSDOS-System heraus gestartet. |
mbr | V:0, I:10 | 50 | Nicht unterstützt | MBR von Neil Turton | Dies ist freie Software, die den MSDOS-MBR ersetzt. Unterstützt nur Festplattenpartitionen. |
![]() |
Warnung |
---|---|
Do not play with boot loaders without having bootable rescue media (USB
memory stick, CD or floppy) created from images in the
|
Bei GRUB Legacy ist die Datei zur Konfiguration des Menüs unter
"/boot/grub/menu.lst
" abgelegt. Sie enthält zum Beispiel
Einträge wie den folgenden:
title Debian GNU/Linux root (hd0,2) kernel /vmlinuz root=/dev/hda3 ro initrd /initrd.img
Bei GRUB 2 ist die Datei zur Konfiguration des Menüs unter
"/boot/grub/grub.cfg
" gespeichert. Sie wird automatisch
durch "/usr/sbin/update-grub
" unter Verwendung von
Vorlagen aus "/etc/grub.d/*
" und Einstellungen aus
"/etc/default/grub
" erzeugt. Die Einträge sehen aus wie
folgt:
menuentry "Debian GNU/Linux" { set root=(hd0,3) linux /vmlinuz root=/dev/hda3 initrd /initrd.img }
Die GRUB-Parameter in diesen Beispielen haben folgende Bedeutungen:
Tabelle 3.2. Bedeutung der GRUB-Parameter
GRUB-Parameter | Bedeutung |
---|---|
root
|
Verwendung der dritten Partition auf der primären Festplatte, welche bei
GRUB Legacy über "(hd0,2) " angegeben wird und bei GRUB 2
über "(hd0,3) ".
|
kernel
|
Verwendung des Kernels unter "/vmlinuz " mit den
Parametern "root=/dev/hda3 ro "
|
initrd
|
Verwendung des initrd/initramfs-Images unter
"/initrd.img "
|
![]() |
Anmerkung |
---|---|
Der Wert der Partitionsnummer, wie er von GRUB Legacy verwendet wird, ist um 1 kleiner als der normal durch den Linux-Kernel und andere Werkzeuge genutzte. Das GRUB-2-Programm behebt dieses Problem. |
![]() |
Tipp |
---|---|
Die UUID-Kennung (lesen Sie dazu Abschnitt 9.5.3, „Zugriff auf Partitionen über die UUID-Kennung“) kann statt dem Gerätenamen
(z.B. " |
![]() |
Tipp |
---|---|
Bei der Nutzung von GRUB sind die
Kernel-Boot-Parameter in |
![]() |
Tipp |
---|---|
Sie können über einen Bootloader einen weiteren Bootloader starten, diese Technik nennt man Chain loading. |
Weitere Infos finden Sie unter "info grub
" und
grub-install(8).
Das Mini-Debian-System ist die dritte Stufe des Boot-Prozesses und wird durch den Bootloader gestartet. Es lässt den System-Kernel mit seinem eigenen Wurzeldateisystem im Speicher laufen. Dies ist ein optionaler, vorbereitender Schritt des Boot-Prozesses.
![]() |
Anmerkung |
---|---|
Der Begriff "Mini-Debian-System" wurde von dem Autor erfunden, um diese dritte Stufe des Boot-Prozesses in diesem Dokument zu beschreiben. Dieses System wird normalerweise initrd- oder initramfs-System genannt. Ein ähnliches System wird im Speicher auch durch den Debian Installer verwendet. |
The "/init
" program is executed as the first program in
this root filesystem on the memory. It is a program which initializes the
kernel in user space and hands control over to the next stage. This
mini-Debian system offers flexibility to the boot process such as adding
kernel modules before the main boot process or mounting the root filesystem
as an encrypted one.
The "/init
" program is a shell script program if
initramfs was created by initramfs-tools
. You can interrupt this part of the boot process to gain root
shell by providing "break=init
" etc. to the kernel boot
parameter. See the "/init
" script for more break
conditions. This shell environment is sophisticated enough to make a good
inspection of your machine's hardware. Commands available in
this mini-Debian system are stripped down ones and mainly provided by a GNU
tool called
busybox(1).
The "/init
" program is a binary
systemd
program if initramfs was created by
dracut
. ** Commands available in this mini-Debian system
are stripped down
systemd(1)
environment.
![]() |
Achtung |
---|---|
Sie müssen die Option " |
Das normale Debian-System ist die vierte Stufe des Boot-Prozesses und wird von dem Mini-Debian-System gestartet. Der System-Kernel des Mini-Debian-Systems läuft in dieser Umgebung weiter. Das verwendete Wurzeldateisystem wird von dem im Arbeitsspeicher umgeschwenkt zu dem auf der echten Festplatte.
Das Programm init wird als erstes Programm mit
PID=1 ausgeführt und erledigt die eigentliche Hauptarbeit beim Booten, das
Starten verschiedener Programme. Der Standardpfad zum init-Programm ist
"/sbin/init
", aber er kann über einen
Kernel-Boot-Parameter wie "init=/pfad/zum/init-programm
"
auch geändert werden.
Das Standard-Init-Programm hat sich im Laufe der Zeit verändert:
Vor Squeeze
verwendete Debian das einfache SysV-artige Init.
Debian Wheezy
verbesserte das SysV-ähnliche Init durch
Sortierung der Boot-Reihenfolge mittels LSB-Header und parallelen Start der
Boot-Skripte.
Debian Jessie
schwenkt um auf systemd, ein ereignisbasiertes Init-System mit
paralleler Initialisierung.
![]() |
Tipp |
---|---|
Mittels " |
![]() |
Tipp |
---|---|
" |
Tabelle 3.3. Liste von Boot-Hilfsprogrammen für das Debian-System
Paket | Popcon | Größe | Beschreibung |
---|---|---|---|
systemd
|
V:703, I:805 | 11933 |
Ereignis-basierter
init(8)-Daemon
für gleichzeitige Ausführung (Alternative zu sysvinit )
|
systemd-sysv
|
V:684, I:798 | 112 |
the manual pages and links needed for systemd to replace
sysvinit
|
systemd-cron
|
V:0, I:1 | 133 | systemd units to provide cron daemon
and anacron functionality
|
init-system-helpers
|
V:704, I:826 | 129 |
helper tools for switching between sysvinit and
systemd
|
initscripts
|
V:284, I:667 | 205 | Skripte zur Initialisierung und zum Herunterfahren des Systems |
sysvinit-core
|
V:13, I:17 | 225 | System-V-ähnliche init(8)-Werkzeuge |
sysv-rc
|
V:477, I:673 | 123 | System-V-ähnlicher Mechanismus zum Wechsel des Runlevels |
sysvinit-utils
|
V:791, I:999 | 110 | System-V-ähnliche Werkzeuge (startpar(8), bootlogd(8), …) |
lsb-base
|
V:877, I:999 | 49 | Zur Linux Standard Base 3.2 konforme init-Skript-Funktionalität |
insserv
|
V:539, I:660 | 140 | Werkzeug, um die Boot-Reihenfolge unter Verwendung von LSB-konformen init.d-Skript-Abhängigkeiten zu organisieren |
uswsusp
|
V:4, I:11 | 699 | Werkzeuge, um das durch Linux bereitgestellte Userspace-Software-Suspend zu verwenden |
kexec-tools
|
V:1, I:8 | 270 | Werkzeug für kexec(8)-Neustarts (Warmstarts) |
systemd-bootchart
|
V:0, I:0 | 122 | Performance-Analyseprogramm für den Boot-Prozess |
bootchart2
|
V:0, I:1 | 94 | Performance-Analyseprogramm für den Boot-Prozess |
pybootchartgui
|
V:0, I:1 | 177 | Performance-Analyseprogramm für den Boot-Prozess (Visualisierung) |
mingetty
|
V:0, I:3 | 35 | getty(8) nur für die Konsole |
mgetty
|
V:0, I:1 | 301 | Intelligenter getty(8)-Ersatz für Modems |
![]() |
Tipp |
---|---|
Unter Debian Wiki: BootProcessSpeedup finden Sie aktuelle Tipps zur Beschleunigung des Boot-Prozesses. |
This section describes how system is started by the
systemd(1)
program with PID=1
(i.e., init process).
The systemd
init process spawns processes in parallel
based on the unit configuration files (see
systemd.unit(5))
which are written in declarative style instead of SysV-like procedural
style. These are loaded from a set of paths (see
systemd-system.conf(5))
as follows:
"/lib/systemd/system
": OS default configuration files
"/etc/systemd/system
": system administrator configuration
files which override the OS default configuration files
"/run/systemd/system
": run-time generated configuration
files which override the installed configuration files
Their inter-dependencies are specified by the directives
"Wants=
", "Requires=
",
"Before=
", "After=
", … (see "MAPPING
OF UNIT PROPERTIES TO THEIR INVERSES" in
systemd.unit(5)).
The resource controls are also defined (see
systemd.resource-control(5)).
The suffix of the unit configuration file encodes their types as:
*.service describes the process
controlled and supervised by systemd
. See
systemd.service(5).
*.device describes the device exposed in the sysfs(5) as udev(7) device tree. See systemd.device(5).
*.mount describes the file system mount
point controlled and supervised by systemd
. See
systemd.mount(5).
*.automount describes the file system
auto mount point controlled and supervised by
systemd
. See
systemd.automount(5).
*.swap describes the swap device or file
controlled and supervised by systemd
. See
systemd.swap(5).
*.path describes the path monitored by
systemd
for path-based activation. See
systemd.path(5).
*.socket describes the socket controlled
and supervised by systemd
for socket-based
activation. See
systemd.socket(5).
*.timer describes the timer controlled
and supervised by systemd
for timer-based activation. See
systemd.timer(5).
*.slice manages resources with the cgroups(7). See systemd.slice(5).
*.scope is created programmatically using
the bus interfaces of systemd
to manages a set of system
processes. See
systemd.scope(5).
*.target groups other unit configuration files to create the synchronization point during start-up. See systemd.target(5).
Upon system start up (i.e., init), the systemd
process
tries to start the "/lib/systemd/system/default.target
(normally symlinked to "graphical.target
"). First, some
special target units (see
systemd.special(7))
such as "local-fs.target
",
"swap.target
" and "cryptsetup.target
"
are pulled in to mount the filesystems. Then, other target units are also
pulled in by the target unit dependencies. For details, read
bootup(7).
systemd
offers backward compatibility features.
SysV-style boot scripts in
"/etc/init.d/rc[0123456S].d/[KS]<name>
" are still
parsed and
telinit(8)
is translated into systemd unit activation requests.
![]() |
Achtung |
---|---|
Emulated runlevel 2 to 4 are all symlinked to the same
" |
The kernel maintains the system hostname. The system unit started by
systemd-hostnamed.service
sets the system hostname at
boot time to the name stored in "/etc/hostname
". This
file should contain only the system
hostname, not a fully qualified domain name.
Um den derzeitigen Rechnernamen auszugeben, führen Sie hostname(1) ohne ein Argument aus.
The mount options of normal disk and network filesystems are set in
"/etc/fstab
". See
fstab(5)
and Abschnitt 9.5.7, „Optimierung von Dateisystemen über mount-Optionen“.
The configuration of the encrypted filesystem is set in
"/etc/crypttab
". See
crypttab(5)
The configuration of software RAID with
mdadm(8)
is set in "/etc/mdadm/mdadm.conf
". See
mdadm.conf(5).
![]() |
Warnung |
---|---|
Bei jedem Systemstart werden nach dem Einbinden aller Dateisysteme temporäre
Dateien in " |
Network interfaces are typically initialized in
"networking.service
" for the lo
interface and "NetworkManager.service
" for other
interfaces on modern Debian desktop system under systemd
.
See Kapitel 5, Netzwerkkonfiguration for how to configure them.
The kernel error message displayed to the console can be configured by setting its threshold level.
# dmesg -n3
Tabelle 3.4. Liste der Anzeigestufe für Kernel-Fehler
Wert der Anzeigestufe | Name der Anzeigestufe | Bedeutung |
---|---|---|
0 | KERN_EMERG | System ist unbenutzbar |
1 | KERN_ALERT | es ist unverzüglich eine Aktion erforderlich |
2 | KERN_CRIT | Zustände mit kritischen Fehlern |
3 | KERN_ERR | Zustände mit Fehlern |
4 | KERN_WARNING | Zustände mit Warnungen |
5 | KERN_NOTICE | normale, aber erwähnenswerte Zustände |
6 | KERN_INFO | rein informativ |
7 | KERN_DEBUG | Nachrichten zur Fehlersuche/-eingrenzung |
Under systemd
, both kernel and system messages are logged
by the journal service systemd-journald.service
(a.k.a
journald
) either into a persistent binary data below
"/var/log/journal
" or into a volatile binary data below
"/run/log/journal/
". These binary log data are accessed
by the
journalctl(1)
command.
Under systemd
, the system logging utility
rsyslogd(8)
changes its behavior to read the volatile binary log data (instead of
pre-systemd default "/dev/log
") and to create traditional
permanent ASCII system log data.
Die Systemmeldungen können über "/etc/default/rsyslog
"
und "/etc/rsyslog.conf
" sowohl für die Protokolldatei wie
auch für die Bildschirmanzeige angepasst werden. Lesen Sie dazu
rsyslogd(8)
und
rsyslog.conf(5)
sowie auch Abschnitt 9.2.2, „Analyseprogramme für Logdateien“.
The systemd
offers not only init system but also generic
system management functionalities such as journal logging, login management,
time management, network management. etc..
The systemd(1) is managed by several commands:
the
systemctl(1)
command controls the systemd
system and service manager
(CLI),
the
systemsdm(1)
command controls the systemd
system and service manager
(GUI),
the
journalctl(1)
command queries the systemd
journal,
the
loginctl(1)
command controls the systemd
login manager, and
the systemd-analyze(1) analyzes system boot-up performance.
Here are a list of typical systemd
management command
snippets. For the exact meanings, please read the pertinent manpages.
Tabelle 3.5. List of typical systemd
management command snippets
Operation | Type | Command snippets |
---|---|---|
GUI for service manager | GUI |
"systemadm " (systemd-ui package)
|
List all target unit configuration | Unit |
"systemctl list-units --type=target "
|
List all service unit configuration | Unit |
"systemctl list-units --type=service "
|
List all unit configuration types | Unit |
"systemctl list-units --type=help "
|
List all socket units in memory | Unit |
"systemctl list-sockets "
|
List all timer units in memory | Unit |
"systemctl list-timers "
|
Start "$unit "
|
Unit |
"systemctl start $unit "
|
Stop "$unit "
|
Unit |
"systemctl stop $unit "
|
Reload service-specific configuration | Unit |
"systemctl reload $unit "
|
Stop and start all "$unit "
|
Unit |
"systemctl restart $unit "
|
Start "$unit " and stop all others
|
Unit |
"systemctl isolate $unit "
|
Switch to "graphical " (GUI system)
|
Unit |
"systemctl isolate graphical "
|
Switch to "multi-user " (CLI system)
|
Unit |
"systemctl isolate multi-user "
|
Switch to "rescue " (single user CLI system)
|
Unit |
"systemctl isolate rescue "
|
Send kill signal to "$unit "
|
Unit |
"systemctl kill $unit "
|
Send kill signal to "$unit "
|
Unit |
"systemctl kill $unit "
|
Check if "$unit " service is active
|
Unit |
"systemctl is-active $unit "
|
Check if "$unit " service is failed
|
Unit |
"systemctl is-failed $unit "
|
Check status of "$unit|$PID|device "
|
Unit |
"systemctl status $unit|$PID|$device "
|
Show properties of "$unit|$job "
|
Unit |
"systemctl show $unit|$job "
|
Reset failed "$unit "
|
Unit |
"systemctl reset-failed $unit"
|
List dependency of all unit services | Unit |
"systemctl list-dependencies --all "
|
List unit files installed on the system | Unit file |
"systemctl list-unit-files "
|
Enable "$unit " (add symlink)
|
Unit file |
"systemctl enable $unit "
|
Disable "$unit " (remove symlink)
|
Unit file |
"systemctl disable $unit "
|
Unmask "$unit " (remove symlink to
"/dev/null ")
|
Unit file |
"systemctl unmask $unit "
|
Mask "$unit " (add symlink to
"/dev/null ")
|
Unit file |
"systemctl mask $unit "
|
Get default-target setting | Unit file |
"systemctl get-default "
|
Set default-target to "graphical " (GUI system)
|
Unit file |
"systemctl set-default graphical "
|
Set default-target to "multi-user " (CLI system)
|
Unit file |
"systemctl set-default multi-user "
|
Show job environment | Environment |
"systemctl show-environment "
|
Set job environment "variable " to
"value "
|
Environment |
"systemctl set-environment variable=value "
|
Unset job environment "variable "
|
Environment |
"systemctl unset-environment variable "
|
Reload all unit files and daemons | Lifecycle |
"systemctl daemon-reload "
|
Shut down the system | System |
"systemctl poweroff "
|
Shut down and reboot the system | System |
"systemctl reboot "
|
Suspend the system | System |
"systemctl suspend "
|
Hibernate the system | System |
"systemctl hibernate "
|
View job log of "$unit "
|
Journal |
"journalctl -u $unit "
|
View job log of "$unit " ("tail -f "
style)
|
Journal |
"journalctl -u $unit -f "
|
Show time spent for each initialization steps | Analyze |
"systemd-analyze time "
|
List of all units by the time to initialize | Analyze |
"systemd-analyze blame "
|
Load and detect errors in "$unit " file
|
Analyze |
"systemd-analyze verify $unit "
|
Track boot process by the cgroups(7) | Cgroup |
"systemd-cgls "
|
Track boot process by the cgroups(7) | Cgroup |
"ps xawf -eo pid,user,cgroup,args "
|
Track boot process by the cgroups(7) | Cgroup |
Read sysfs under
"/sys/fs/cgroup/systemd/ "
|
Here, "$unit
" in the above examples may be a single unit
name (suffix such as .service
and
.target
are optional) or, in many cases, multiple unit
specifications (shell-style globs "*
",
"?
", "[]
" using
fnmatch(3)
which will be matched against the primary names of all units currently in
memory).
System state changing commands in the above examples are typically preceded
by the "sudo
" to attain the required administrative
privilege.
The output of the "systemctl status $unit|$PID|$device
"
uses color of the dot ("●") to summarize the unit state at a glance.
White "●" indicates an "inactive" or "deactivating" state.
Red "●" indicates a "failed" or "error" state.
Green "●" indicates an "active", "reloading" or "activating" state.
With default installation, many network services (see Kapitel 6, Netzwerkapplikationen) are started as daemon processes after
network.target
at boot time by
systemd
. The "sshd
" is no exception.
Let's change this to on-demand start of "sshd
" as a
customization example.
First, disable system installed service unit.
$ sudo systemctl stop sshd.service $ sudo systemctl mask sshd.service
The on-demand socket activation system of the classic Unix services was
through the indetd
superserver. Under
systemd
, the equivalent can be enabled by adding
*.socket and *.service unit configuration files.
sshd.socket
for specifying a socket to listen on
[Unit] Description=SSH Socket for Per-Connection Servers [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target
sshd@.service
as the matching service file of
sshd.socket
[Unit] Description=SSH Per-Connection Server [Service] ExecStart=-/usr/sbin/sshd -i StandardInput=socket
Then reload.
$ sudo systemctl daemon-reload
Für Linux-Kernel der 2.6-Reihe und neuer bietet das udev-System Mechanismen für automatische Hardware-Erkennung und -initialisierung (lesen Sie dazu udev(7)). Nach der Erkennung eines Gerätes durch den Kernel startet das udev-System einen User-Prozess. Dieser verwendet Informationen aus dem sysfs-Dateisystem (Näheres in Abschnitt 1.2.12, „procfs und sysfs“), lädt über den Befehl modprobe(8) benötigte Kernel-Module, die die Hardware unterstützen (Details in Abschnitt 3.3.1, „Die Kernel-Modul-Initialisierung“), und erstellt die zugehörigen Geräteknoten (device nodes).
![]() |
Tipp |
---|---|
Falls " |
Die Namen der Geräteknoten können über udev-Regel-Dateien in
"/etc/udev/rules.d/
" konfiguriert werden. Aktuelle
Standardregeln neigen dazu, dynamisch generierte Namen zu erzeugen, was
(außer bei CD- und Netzwerkgeräten) dazu führt, dass sich die Gerätenamen
von Mal zu Mal ändern. Indem Sie Ihre eigenen Regeln hinzufügen (ähnlich
denen für CD- und Netzwerkgeräte), können Sie auch für andere Geräte wie
z.B. USB-Memory-Sticks fest zugeordnete Gerätenamen vergeben. Lesen Sie dazu
"Writing udev rules" oder
"/usr/share/doc/udev/writing_udev_rules/index.html
".
Da das udev-System immer ein wenig im Wandel ist, überlasse ich die Details anderen Dokumenten und beschränke mich hier auf das Nötigste.
![]() |
Tipp |
---|---|
Für die Regeln zum Einbinden von Dateisystemen in
" |
Das modprobe(8)-Programm erlaubt es, einen laufenden Linux-Kernel über einen User-Prozess zu konfigurieren, indem Kernel-Module hinzugefügt und entfernt werden. Das udev-System (Näheres in Abschnitt 3.3, „Das udev-System“) automatisiert dessen Aufruf, um bei der Initialisierung des Kernel-Moduls zu helfen.
Es gibt Module, die nicht zu bestimmter Hardware gehören, sowie spezielle
Hardware-Treibermodule wie die folgenden, die im Voraus geladen werden
müssen, indem Sie in die Datei "/etc/modules
" eingetragen
werden (Details in
modules(5)):
TUN/TAP-Module, die ein virtuelles Point-to-Point Netzwerkgerät (TUN) und ein virtuelles Ethernet-Netzwerkgerät (TAP) bereitstellen;
netfilter-Module, die Netfilter-Firewall-Funktionalitäten bereitstellen (lesen Sie dazu iptables(8) und Abschnitt 5.10, „Die Netfilter-Infrastruktur“);
watchdog timer-Treibermodule.
Die Konfigurationsdateien für das
modprobe(8)-Programm
sind unterhalb des "/etc/modprobes.d/
"-Verzeichnisses
abgelegt, wie in
modprobe.conf(5)
beschrieben. (Falls Sie vermeiden möchten, dass einige Kernel-Module
automatisch geladen werden, sollten Sie erwägen, diese in die Datei
"/etc/modprobes.d/blacklist
" einzutragen.)
Die Datei "/lib/modules/<version>/modules.dep
"
(erzeugt durch das Programm
depmod(8))
beschreibt Abhängigkeiten zwischen den Modulen; diese Abhängigkeiten werden
von
modprobe(8)
genutzt.
![]() |
Anmerkung |
---|---|
Wenn Sie Probleme beim Laden von Modulen feststellen, entweder während des
Systemstarts oder beim Nachladen mit
modprobe(8),
kann " |
Der Befehl modinfo(8) zeigt Informationen über ein Linux-Kernel-Modul an.
Das
lsmod(8)-Programm
formatiert den Inhalt von "/proc/modules
" zu einer
hübschen Ausgabe, um anzuzeigen, welche Kernel-Module gerade geladen sind.
![]() |
Tipp |
---|---|
Sie können die Hardware in Ihrem System exakt identifizieren. Lesen Sie dazu Abschnitt 9.4.3, „Hardware-Identifikation“. |
![]() |
Tipp |
---|---|
Möglicherweise wollen Sie Hardware während des Systemstarts konfigurieren, um bestimmte erwartete Hardware-Funktionalitäten zu aktivieren. Näheres finden Sie in Abschnitt 9.4.4, „Hardware-Konfiguration“. |
![]() |
Tipp |
---|---|
Unterstützung für spezielle Geräte können Sie unter Umständen durch Neukompilieren des Kernels hinzufügen. Details finden Sie in Abschnitt 9.9, „Der Kernel“. |