De nombreux scripts sysv init utilisaient un fichier correspondant dans /etc/default
pour permettre à l'administrateur de le configurer. Les travaux Upstart peuvent être modifiés à l'aide des fichiers .override
. Comment remplacer ou configurer des unités systemd, maintenant que systemd est la valeur par défaut dans Ubuntu?
Les unités systemd
n'ont pas besoin d'obéir aux fichiers de /etc/default
. systemd
est facilement configurable, mais vous devez connaître la syntaxe des fichiers d'unité systemd.
Les colis sont généralement expédiés dans /lib/systemd/system/
. Ce ne sont pas à éditer. systemd
vous permet plutôt de remplacer ces fichiers en créant les fichiers appropriés dans /etc/systemd/system/
.
Pour un service donné foo
, le package fournirait /lib/systemd/system/foo.service
. Vous pouvez vérifier son statut à l'aide de systemctl status foo
ou afficher ses journaux à l'aide de journalctl -u foo
. Pour remplacer quelque chose dans la définition de foo
, faites:
Sudo systemctl edit foo
Cela crée un répertoire dans /etc/systemd/system
nommé d'après l'unité et un fichier override.conf
dans ce répertoire (/etc/systemd/system/foo.service.d/override.conf
). Vous pouvez ajouter ou remplacer des paramètres à l'aide de ce fichier (ou d'autres fichiers .conf
dans /etc/systemd/system/foo.service.d/
).
Prenez le service getty
par exemple. Dites que je veux avoir TTY2 connexion automatique à mon utilisateur (ce n'est pas conseillé, mais juste un exemple). TTY2 est exécuté par le service getty@tty2
(tty2
étant une instance du modèle /lib/systemd/system/getty@service
). Pour ce faire, je dois modifier le service getty@tty2
.
$ systemctl cat getty@tty2
# /lib/systemd/system/[email protected]
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service
# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes
# On systems without virtual consoles, don't start any getty. Note
# that serial gettys are covered by [email protected], not this
# unit.
ConditionPathExists=/dev/tty0
[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear %I $TERM
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes
# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=
[Install]
WantedBy=getty.target
DefaultInstance=tty1
En particulier, je dois modifier la ligne ExecStart
, qui est actuellement:
$ systemctl cat getty@tty2 | grep Exec
ExecStart=-/sbin/agetty --noclear %I $TERM
Pour annuler cela, faites:
Sudo systemctl edit getty@tty2
Et ajouter:
[Service]
ExecStart=
ExecStart=-/sbin/agetty -a muru --noclear %I $TERM
Notez que:
ExecStart
avant de le redéfinir, car il s’agit d’un paramètre additif, similaire à After
, Environment
(dans son ensemble, pas par variable) et EnvironmentFile
, et opposé aux paramètres prioritaires tels que RestartSec
ou Type
. ExecStart
peut avoir plusieurs entrées uniquement pour les services Type=oneshot
.ExecStart
se trouve dans la section [Service]
; mon remplacement doit donc mettre ExecStart
dans la section [Service]
également. Souvent, consulter le fichier de service actuel à l'aide de systemctl cat
vous indiquera ce que vous devez remplacer et dans quelle section il se trouve.Habituellement, si vous éditez un fichier unité systemd pour que celui-ci prenne effet, vous devez exécuter:
Sudo systemctl daemon-reload
Cependant, systemctl edit
le fait automatiquement pour vous.
À présent:
$ systemctl cat getty@tty2 | grep Exec
ExecStart=-/sbin/agetty --noclear %I $TERM
ExecStart=
ExecStart=-/sbin/agetty -a muru --noclear %I $TERM
$ systemctl show getty@tty2 | grep ExecS
ExecStart={ path=/sbin/agetty ; argv[]=/sbin/agetty -a muru --noclear %I $TERM ; ... }
Et si je le fais:
Sudo systemctl restart getty@tty2
et appuyez sur CtrlAltF2, hop! Je serai connecté à mon compte sur ce téléscripteur.
Comme je l'ai déjà dit, getty@tty2
est une instance d'un modèle. Alors, si je voulais remplacer toutes les instances de ce modèle? Cela peut être fait en modifiant le modèle lui-même (en supprimant l'identificateur d'instance - dans ce cas, tty2
):
systemctl edit getty@
Un cas d'utilisation courant des fichiers /etc/default
consiste à définir des variables d'environnement. /etc/default
étant généralement un script Shell, vous pouvez y utiliser des constructions de langage Shell. Avec systemd
, cependant, ce n'est pas le cas. Vous pouvez spécifier des variables d'environnement de deux manières:
Supposons que vous ayez défini les variables d'environnement dans un fichier:
$ cat /path/to/some/file
FOO=bar
Ensuite, vous pouvez ajouter à la substitution:
[Service]
EnvironmentFile=/path/to/some/file
En particulier, si votre /etc/default/grub
ne contient que des assignations et aucune syntaxe de shell, vous pouvez l’utiliser comme EnvironmentFile
.
Environment
Ce qui précède pourrait également être accompli en utilisant le remplacement suivant:
[Service]
Environment=FOO=bar
Cependant, cela peut devenir délicat avec plusieurs variables, espaces, etc. Regardez ne de mes autres réponses pour un exemple d'un tel exemple.
Via ce mécanisme, il devient très facile de remplacer les unités systemd
, ainsi que d’annuler ces modifications (en supprimant simplement le fichier de substitution). Ce ne sont pas les seuls paramètres qui peuvent être modifiés.
Les liens suivants seraient utiles:
systemd
systemd
, en particulier les pages de manuel de systemd.unit
et systemd.service