Il n'est pas vraiment nécessaire de désactiver les TTY "supplémentaires" comme sous systemd les gettys sont générés à la demande :voir man systemd-getty-generator pour plus de détails. Notez que, par défaut, cette génération automatique est effectuée pour les VT jusqu'à VT6 uniquement (pour imiter les systèmes Linux traditionnels).
Comme le dit Lennart dans un article de blog :
Afin de rendre les choses plus efficaces, les invites de connexion sont désormais lancées uniquement à la demande. Lorsque vous passez aux VT, le service getty est instancié à [email protected], [email protected] et ainsi de suite. Comme nous n'avons plus besoin de démarrer inconditionnellement les processus getty, cela nous permet d'économiser un peu de ressources et rend le démarrage un peu plus rapide.
Si vous souhaitez configurer un nombre spécifique de gettys, vous pouvez simplement modifier logind.conf avec l'entrée appropriée, dans cet exemple 3 :
NAutoVTs=3
Sur les systèmes basés sur Debian, il existe un fichier qui provoque le lancement de 5 getty supplémentaires au démarrage si vous venez de construire un serveur (sans service dbus) :
/lib/systemd/system/getty.target.wants/getty-static.service
Dedans, il est écrit :
[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start [email protected] [email protected] [email protected] [email protected] [email protected]
RemainAfterExit=true
Le simple fait de supprimer ce fichier empêchera les getty supplémentaires de se reproduire. N'hésitez pas à raccourcir la liste si vous souhaitez juste générer un getty supplémentaire (pour 2 consoles virt). Notez que vous en obtenez automatiquement une sur tty1, vous avez donc toujours au moins une console virtuelle.
Voir aussi :systemd-logind.service ne démarre pas si dbus est manquant
Pour désactiver gettys sur des TTY particuliers 4-6 tout en laissant éventuellement 1-3 et 7-9 fonctionner, exécutez :
for i in {4..6}; do
systemctl mask [email protected]${i}.service
done
mask crée le lien symbolique /etc/systemd/system/{name} -> /dev/null qui désactive effectivement le service. Essayez de l'exécuter via systemctl start affichera l'erreur Failed to start NAME.service: Unit NAME.service is masked.
Si vous avez A.service Wants=masked.service , puis start A réussira mais générera également une erreur de démarrage de dépendance dans le journal.
Si vous avez B.service Requires=masked.service , puis start B échouera également.
Oui, nécroréponse. Bravo.