Es besteht keine wirkliche Notwendigkeit, "zusätzliche" TTYs wie unter systemd zu deaktivieren Gettys werden bei Bedarf generiert:siehe man systemd-getty-generator für Details. Beachten Sie, dass dieses automatische Spawnen standardmäßig nur für die VTs bis VT6 durchgeführt wird (um traditionelle Linux-Systeme nachzuahmen).
Wie Lennart in einem Blogbeitrag sagt:
Um die Dinge effizienter zu machen, werden Anmeldeaufforderungen jetzt nur noch bei Bedarf gestartet. Wenn Sie zu den VTs wechseln, wird der getty-Dienst zu [email protected], [email protected] und so weiter instanziiert. Da wir die getty-Prozesse nicht mehr bedingungslos starten müssen, können wir etwas Ressourcen sparen und den Start etwas beschleunigen.
Wenn Sie eine bestimmte Anzahl von Gettys konfigurieren möchten, können Sie einfach logind.conf ändern mit dem entsprechenden Eintrag, in diesem Beispiel 3:
NAutoVTs=3
Auf Debian-basierten Systemen gibt es eine Datei, die bewirkt, dass beim Start 5 zusätzliche gettys gestartet werden, wenn Sie gerade einen Server (ohne dbus-Dienst) gebaut haben:
/lib/systemd/system/getty.target.wants/getty-static.service
Darin heißt es:
[Service]
Type=oneshot
ExecStart=/bin/systemctl --no-block start [email protected] [email protected] [email protected] [email protected] [email protected]
RemainAfterExit=true
Das einfache Löschen dieser Datei stoppt das Spawnen der zusätzlichen Gettys. Fühlen Sie sich frei, die Liste zu kürzen, wenn Sie nur einen zusätzlichen Getty spawnen möchten (für 2 Virt-Konsolen). Beachten Sie, dass Sie automatisch eine auf tty1 erhalten, sodass Sie immer mindestens eine virtuelle Konsole haben.
Siehe auch:systemd-logind.service startet nicht, wenn dbus fehlt
Um Gettys auf bestimmten TTYs 4-6 zu deaktivieren, während 1-3 und 7-9 möglicherweise weiterarbeiten, führen Sie Folgendes aus:
for i in {4..6}; do
systemctl mask [email protected]${i}.service
done
mask erstellt Symlink /etc/systemd/system/{name} -> /dev/null wodurch der Dienst effektiv deaktiviert wird. Versuchen Sie, es über systemctl start auszuführen zeigt den Fehler Failed to start NAME.service: Unit NAME.service is masked. an
Wenn Sie A.service Wants=masked.service haben , dann start A wird erfolgreich sein, aber auch einen Abhängigkeitsstartfehler im Journal generieren.
Wenn Sie B.service Requires=masked.service haben , dann start B wird ebenfalls fehlschlagen.
Ja, Nekroantwort. Prost.