Le fichier /etc/systemd/system.conf
contient un ensemble d'options pour contrôler les opérations de
base de systemd. Le fichier par défaut a toutes ses entrées
commentées indiquant les paramètres par défaut. Ce fichier est
l'endroit où le niveau de journalisation (log) peut être modifié
ainsi que les paramètres de base de journalisation. Voir la page de
manuel de systemd-system.conf(5)
pour
plus de détails à propos de chaque option de configuration.
Le comportement normal de systemd est d'effacer l'écran à la fin de la séquence de démarrage. Si désiré, ce comportement peut être changé en exécutant la commande suivante :
mkdir -pv /etc/systemd/system/getty@tty1.service.d
cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF
Les messages de démarrage peuvent toujours être examinés en
utilisant la commande journalctl
-b
en tant qu'utilisateur root.
Par défaut, /tmp
est créé comme un
tmpfs. Si vous ne le voulez pas, il est possible de l'en empêcher
de la manière suivante :
ln -sfv /dev/null /etc/systemd/system/tmp.mount
Autrement, si vous souhaitez avoir une partition séparée pour
/tmp
, spécifiez-la dans une entrée de
/etc/fstab
.
Ne créez pas le lien symbolique ci-dessus si vous utilisez une
partition séparée pour /tmp
. Cela
empêche la partition racine (/) d'être remontée en
lecture-écriture et rend le système inutilisable au démarrage.
Il existe de nombreux services pour créer ou supprimer des fichiers ou des dossiers :
systemd-tmpfiles-clean.service
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service
L'emplacement système des fichiers de configuration est
/usr/lib/tmpfiles.d/*.conf
. Les
fichiers locaux de configuration sont dans /etc/tmpfiles.d
. Les fichiers dans /etc/tmpfiles.d
prévallent sur les fichiers du
même nom dans /usr/lib/tmpfiles.d
.
Voir la page de manuel tmpfiles.d(5)
pour plus de détails sur le format de fichier.
Remarquez que la syntaxe pour les fichiers /usr/lib/tmpfiles.d/*.conf
peut être déroutante.
Par exemple, la suppression de fichiers par défaut dans le
répertoire /tmp se trouve dans /usr/lib/tmpfiles.d/tmp.conf
à cette ligne :
q /tmp 1777 root root 10d
. Le champ type, q, parle de créer un sous-volume avec des quotas, ce qui n'est vraiment possible que pour les système de fichiers btrfs. Il référence le type v qui lui-même référence le type d (répertoire). Cela crée ensuite le répertoire spécifié s'il n'est pas présent et ajuste ensuite les permissions et la propriété comme indiqué. Le contenu du répertoire sera sujet au nettoyage basé sur l'âge si l'argument d'âge est spécifié.
Si les paramètres par défaut ne sont pas désirés, alors vous devrez
copier le fichier vers /etc/tmpfiles.d
et le modifier comme vous le
voulez. Par exemple :
mkdir -p /etc/tmpfiles.d cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d
Les paramètres d’une unité peuvent être redéfinis en créant un
dossier et un fichier de configuration dans /etc/systemd/system
. Par exemple :
mkdir -pv /etc/systemd/system/foobar.service.d
cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF
Voir la page de manuel systemd.unit(5)
pour plus d'informations. Après
la création du fichier de configuration, exécutez systemctl daemon-reload
et
systemctl restart
foobar
pour activer les changements à un service.
Plutôt que des scripts shell utilisés par les systèmes d’init du style de SysVinit ou BSD, systemd utilise un format unifié pour différents types de fichiers de démarrage (ou unités). La commande systemctl est utilisée pour activer, désactiver, contrôler l’état et obtenir le statut d’un fichier d’unité. Voici quelques exemples de commandes fréquentes :
systemctl list-units -t
<service>
[--all]: liste les fichiers d’unité chargés
de type service.
systemctl list-units -t
<target>
[--all]: liste les fichiers d’unité chargés
de type target.
systemctl show -p Wants
<multi-user.target>
:
montre toutes les unités qui dépendent de la cible
multi-user. Les cibles sont des fichiers d’unité spéciaux qui
sont analogues aux niveaux d’exécution de SysVinit.
systemctl status <servicename.service>
:
montre le statut du service servicename. L’extension .service
peut être omise s’il n’y a pas d’autres fichiers d’unité
portant le même nom, comme des fichiers .socket (qui créent
un socket en écoute qui fourni les même fonctionnalités
qu'inetd/xinetd).
La journalisation d’un système démarré avec systemd est géré par systemd-journald (par défaut), plutôt qu’un démon syslog unix typique. Vous pouvez aussi ajouter un démon syslog normal et faire travailler les deux côte à côte si vous le souhaitez. Le programme systemd-journald stocke les entrées du journal dans un format binaire plutôt que dans un fichier en texte brut. La commande journalctl est fournie pour aider à analyser le fichier. Voici quelques exemples de commandes usuelles :
journalctl -r : montre tout le contenu du journal en sens chronologique inverse.
journalctl -u UNIT
:
montre les entrées du journal associées avec le fichier UNIT
spécifié.
journalctl -b[=ID] -r : montre les entrées du journal depuis le dernier démarrage réussi (ou pour le démarrage d’identifiant ID) en sens chronologique inverse.
journalctl -f : fournit une fonctionnalité similaire à tail -f (suivre).
Les « core dumps » sont utiles pour déboguer des
programmes crashés, surtout quand un processus démon plante. Sur un
système démarré avec systemd, les core dumps sont gérés par
systemd-coredump. Il
enregistrera le core dump das le journal et stockera le fichier
core dans /var/lib/systemd/coredump
.
Pour récupérer et utiliser le fichier core, système fourni l'outil
coredumpctl. Voici
quelques exemples de commandes fréquentes :
coredumpctl -r : montre tous les core dumps en ordre chronologique inverse.
coredumpctl -1 info : montre les informations du dernier core dump.
coredumpctl -1 debug : charge le dernier core dump dans GDB.
Les core dumps peuvent utiliser beaucoup d'espace disque. L'espace
disque maximal utilisé par les core dumps se limite en créant un
fichier de configuration dans /etc/systemd/coredump.conf.d
. Par exemple :
mkdir -pv /etc/systemd/coredump.conf.d
cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF
Voir les pages de manuel systemd-coredump(8)
, coredumpctl(1)
, and coredump.conf.d(5)
pour plus d'information.
Depuis la version systemd-230, tous les processus utilisateurs sont
tués lorsque la session utilisateur se termine, même en utilisant
nohup, ou que le processus utilise les fonctions daemon()
ou setsid()
. Ceci est un changement délibéré par
rapport à un environnement historiquement plus permissif vers un
environnement plus restrictif. Le nouveau comportement peut causer
des problèmes si vous dépendez de programmes lancés durablement
(par exemple, screen
ou tmux) qui restent
actifs après la fin de votre session utilisateur. Il y a trois
moyens de permettre la persistance des processus après la fin d'une
session utilisateur.
N'activez les processus
persistants que pour les utilisateurs qui en ont
besoin : les utilisateurs ont la possibilité
d'activer les processus persistants avec la commande
loginctl
enable-linger pour eux-mêmes. Les
administrateurs systèmes peuvent utiliser la même commande
avec un argument utilisateur
pour les activer
pour un utilisateur. Cet utilisateur peut alors utiliser la
commande systemd-run pour débuter
une tâche durable. Par exemple : systemd-run --scope --user
/usr/bin/screen. Si vous souhaitez activer
les tâches durables pour votre utilisateur, le service
user@.service sera toujours présent même après la fermeture
de toutes les sessions, et démarrera automatiquement au
démarrage du système. Ceci a l'avantage d'autoriser et
d'interdire explicitement aux programmes de s'exécuter après
que la session utilisateur est fermée, mais cela casse la
rétro-compatibilité avec des outils comme nohup et les utilitaires
qui utilisent daemon()
.
Activer les processus persistant
sur tout le système : vous pouvez définir
KillUserProcesses=no
dans /etc/systemd/logind.conf
pour autoriser globalement la persistance pour tous les
utilisateurs. Ceci a l'avantage de laisser disponibles les
vieilles méthodes à tous les utilisateurs au prix de la perte
de contrôle explicite.
Désactiver à la
construction : vous pouvez autoriser les
processus persistants par défaut pendant la construction de
systemd en ajoutant le paramètre -Ddefault-kill-user-processes=false
à la commande meson de systemd. Ceci
désactive complètement la capacité que systemd a de tuer les
processus utilisateurs à la fin de la session.