Scroll to navigation

LOGIND.CONF(5) logind.conf LOGIND.CONF(5)

BEZEICHNUNG

logind.conf, logind.conf.d - Konfigurationsdateien des Anmeldeverwalters

ÜBERSICHT

/etc/systemd/logind.conf

/etc/systemd/logind.conf.d/*.conf

/run/systemd/logind.conf.d/*.conf

/usr/lib/systemd/logind.conf.d/*.conf

BESCHREIBUNG

Diese Dateien konfigurieren verschiedene Parameter des Systemd-Anmeldeverwalters systemd-logind.service(8). Siehe systemd.syntax(7) für eine allgemeine Beschreibung der Syntax.

KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE

Die Standardkonfiguration wird während der Kompilierung definiert. Daher wird eine Konfigurationsdatei nur benötigt, wenn von diesen Vorgaben abgewichen werden muss. Standardmäßig enthält die Konfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten Hinweis für den Administrator. Diese Datei kann bearbeitet werden, um lokal Einstellungen zu ändern.

Wenn Pakete die Konfiguration anpassen müssen, können sie Konfigurationsschnipsel in /usr/lib/systemd/*.conf.d/ oder /usr/local/lib/systemd/*.conf.d/ installieren. Die Hauptkonfigurationsdatei wird vor jeder anderen aus den Konfigurationsverzeichnissen gelesen und hat die niedrigste Priorität; Einträge in einer Datei in jedem der Konfigurationsverzeichnisse setzen Einträge in der einzelnen Konfigurationsdatei außer Kraft. Dateien in den Konfigurationsunterverzeichnissen *.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen sortiert, unabhängig davon, in welchem Unterverzeichnis sie sich befinden. Bei Optionen, die nur einen einzelnen Wert akzeptieren, hat der Eintrag in der Datei mit dem lexikographisch letzten Namen Vorrang, falls mehrere Dateien die gleiche Option angeben. Bei Optionen, die eine Liste von Werten akzeptieren, werden Einträge zusammengefasst, wie sie in den lexikographisch sortierten Dateien auftauchen.

Dateien in /etc/ sind für den lokalen Administrator reserviert, der diese Logik verwenden kann, um die durch die Lieferantenpakete bereitgestellten Konfigurationsdateien außer Kraft zu setzen. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl und einen Bindestrich voranzustellen, um die Sortierung der Dateien zu vereinfachen.

Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu deaktivieren, wird empfohlen, einen Symlink nach /dev/null in dem Konfigurationsverzeichnis in /etc/ mit dem gleichen Dateinamen wie die Konfigurationsdatei des Lieferanten abzulegen.

OPTIONEN

Alle Optionen werden im Abschnitt »[Login]« konfiguriert:

NAutoVTs=

Akzeptiert eine positive Ganzzahl. Konfiguriert, wie viele virtuelle Terminals (VTs) standardmäßig zur Verfügung gestellt werden sollen, bei denen beim Umschalten automatisch »autovt« gestartet werden, wenn sie bisher unbenutzt waren. Diese Dienste werden von der Vorlagen-Unit autovt@.service für den respektiven VT-TTY-Namen initiiert, beispielsweise autovt@tty4.service. Standardmäßig ist autovt@.service auf getty@.service verlinkt. Anders ausgedrückt, Eingabeaufforderungen werden dynamisch gestartet, wenn der Benutzer auf unbenutzte virtuelle Terminals umschaltet. Daher steuert dieser Parameter, wie viele Anmelde-»gettys« auf den VTs verfügbar sind. Falls ein VT bereits von einem anderen Untersystem (beispielsweise einer graphischen Anmeldeaufforderung) benutzt wird, wird diese Form der Aktivierung nicht versucht. Beachten Sie, dass das mit ReserveVT= konfigurierte VT immer dieser Art der Aktivierung unterliegt, selbst falls es nicht eines der mit der Anweisung NAutoVTs= konfigurierten VTs ist. Standardmäßig 6. Wenn auf 0 gesetzt, ist das automatische Starten von »autovt«-Diensten deaktiviert.

ReserveVT=

Akzeptiert eine positive Ganzzahl. Identifiziert ein virtuelles Terminal, das bedingungslos für die autovt@.service-Aktivierung reserviert wird (siehe oben). Das mit dieser Option ausgewählte VT wird bedingungslos als beschäftigt markiert, so dass es keinem anderen Untersystem zur Verfügung gestellt wird. Diese Funktionalität ist nützlich, um sicherzustellen, dass ein Anmelde-»getty« immer verfügbar ist, unabhängig davon, wie viele VTs anderen Untersystemen zur Verfügung gestellt werden. Standardmäßig 6 (mit anderen Worten, es wird immer ein »getty« unter Alt-F6 verfügbar sein). Wenn auf 0 gesetzt, ist die VT-Reservierung deaktiviert.

KillUserProcesses=

Akzeptiert ein logisches Argument. Konfiguriert, ob der Prozess eines Benutzers getötet werden soll, wenn sich der Benutzer abmeldet. Falls wahr, werden die der Sitzung entsprechende Bereichs-Unit und alle im Bereich befindlichen Prozesse beendet. Falls nicht wahr, wird der Bereich »aufgegeben«, siehe systemd.scope(5) und Prozesse werden nicht getötet. Standardmäßig »no«, siehe aber die Optionen KillOnlyUsers= und KillExcludeUsers= unten.

Zusätzlich zu Sitzungsprozessen können Benutzerprozesse unter der Benutzerverwalter-Unit user@.service laufen. Abhängig von den fortbestehenden Einstellungen kann dieses Benutzerprozessen erlauben, Prozesse unabhängig von ihrer Anmeldesitzung auszuführen. Siehe die Beschreibung von enable-linger in loginctl(1).

Beachten Sie, dass die Einstellung KillUserProcesses=yes Werkzeuge wie screen(1) und tmux(1) beschädigen wird, außer sie werden aus dem Geltungsbereich der Sitzung verschoben. Siehe die Beispiele in systemd-run(1).

KillOnlyUsers=, KillExcludeUsers=

Diese Einstellungen akzeptieren eine durch Leerraum getrennte Liste von Benutzernamen, die die Einstellung KillUserProcesses= außer Kraft setzen. Ein Benutzername kann zu KillExcludeUsers= hinzugefügt werden, um die Prozesse in dem Sitzungsgeltungsbereich dieses Benutzers vom Töten auszuschließen, selbst falls KillUserProcesses=yes gesetzt ist. Falls KillExcludeUsers= nicht gesetzt ist, wird standardmäßig der Benutzer »root« ausgeschlossen. KillExcludeUsers= kann auf einen leeren Wert gesetzt werden, um diese Vorgabe außer Kraft zu setzen. Falls ein Benutzer nicht ausgeschlossen ist, wird KillOnlyUsers= als nächstes geprüft. Falls diese Einstellung angegeben ist, werden nur die Prozesse in den Sitzungsgeltungsbereichen dieser Benutzer getötet. Andernfalls unterliegen die Benutzer der Einstellung KillUserProcesses=yes.

IdleAction=

Konfiguriert die Aktion, die unternommen werden soll, wenn sich das System im Leerlauf befindet. Akzeptiert einen Wert aus »ignore«, »poweroff«, »reboot«, »halt«, »kexec«, »suspend«, »hibernate«, »hybrid-sleep«, »suspend-then-hibernate« und »lock«. Standardmäßig »ignore«.

Beachten Sie, dass dies erfordert, dass die Benutzersitzungen den Leerlaufstatus korrekt an das System berichten. Das System wird die Aktion ausführen, nachdem alle Sitzungen berichten, dass sie im Leerlauf sind, keine Unterdrückungssperren aktiv sind und folglicherweise die mit IdleActionSec= (siehe unten) konfigurierte Zeit abgelaufen ist.

IdleActionSec=

Konfiguriert die Verzögerung, nach der die in IdleAction= (siehe oben) konfigurierte Aktion durchgeführt wird, nachdem das System im Leerlauf ist.

InhibitDelayMaxSec=

Legt die maximale Zeit fest, die eine Systemherunterfahr- oder -schlafanfrage aufgrund der Aktivität der Unterdrückungssperre des Typs »delay« verzögert wird, bevor die Unterdrückung ignoriert und die Aktion trotzdem ausgeführt wird. Standardmäßig 5.

UserStopDelaySec=

Legt fest, wie lange der Benutzerdatensatz und der benutzerbezogene Dienst user@.service für einen Benutzer behalten werden soll, nachdem er sich komplett abgemeldet hat. Falls auf Null gesetzt wird der benutzerbezogene Dienst sofort beendet, wenn die letzte Sitzung des Benutzers geendet hat. Falls diese Option auf einen anderen Wert gesetzt wird, werden schnelle Anmelde-/Abmeldezyklen beschleunigt, da der Diensteverwalter des Benutzer nicht immer wieder neu gestartet wird. Falls auf »infinity« gesetzt wird der benutzerbezogene Dienst für einen Benutzer nie nach der ersten Anmeldung beendet und läuft weiter, bis das System heruntergefahren wird. Standardmäßig 10s.

HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch=, HandleLidSwitchExternalPower=, HandleLidSwitchDocked=, HandleRebootKey=

Steuert, wie Logind die System-Einschalt-, Neustart- und -Schlaf-Tasten sowie den Deckelschalter behandeln soll, um Aktionen wie Ausschalten, Neustarten oder Suspendierung auszulösen. Kann eines von »ignore«, »poweroff«, »reboot«, »halt«, »kexec«, »suspend«, »hibernate«, »hybrid-sleep«, »suspend-then-hibernate« und »lock« sein. Falls »ignore«, wird Logind diese Tasten niemals behandeln. Falls »lock« werden alle laufenden Sitzungen mit Bildschirmschonern gesperrt, andernfalls wird die festgelegte Aktion in dem jeweiligen Ereignis vorgenommen. Es werden nur Eingabegeräte mit der Udev-Markierung »power-switch« auf Tasten-/Deckel-Schaltereignisse überwacht. HandlePowerKey= ist standardmäßig »poweroff«, HandleRebootKey= ist standardmäßig »reboot«. HandleSuspendKey= und HandleLidSwitch= sind standardmäßig »suspend«. HandleLidSwitchExternalPower= wird standardmäßig komplett ignoriert (für Rückwartskompatibilität) — es muss ein expliziter Wert gesetzt werden, bevor er für die Verhaltensbestimmung verwandt wird. HandleLidSwitchDocked= ist standardmäßig »ignore«. HandleHibernateKey= ist standardmäßig »hibernate«. Falls das System in eine Docking-Station eingeschoben wird oder falls mehr als ein Monitor angeschlossen wird, tritt die in HandleLidSwitchDocked= festgelegte Aktion ein. Falls das System von Extern Strom bekommt tritt die durch HandleLidSwitchExternalPower= festgelegte Aktion (falls vorhanden) ein, andernfalls tritt die Aktion HandleLidSwitch= ein.

Eine andere Anwendung kann das Behandeln der Einschalt- und Schlaftasten sowie des Deckelschalters durch Logind deaktivieren, indem es eine systemnahe Unterdrückungssperre (»handle-power-key«, »handle-suspend-key«, »handle-hibernate-key«, »handle-lid-switch«, »handle-reboot-switch«) erlangt. Dies wird am Häufigsten von graphischen Desktop-Umgebungen verwandt, um die Suspendierungs- und Ruhezustände-Handhabung zu übernehmen und ihren eigenen Konfigurationsmechanismus zu verwenden. Falls eine systemnahe Unterdrückungssperre erlangt wird, wird Logind keine Aktionen ergreifen, wenn die Taste oder der Schalter ausgelöst wird und die Einstellungen Handle*= sind irrelevant.

PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited=, LidSwitchIgnoreInhibited=, RebootKeyIgnoreInhibited=

Steuert, ob Aktionen, die systemd-logind unternimmt, wenn die Einschalt-, Neustart- und Schlaftaste und der Deckelschalter ausgelöst werden, den anwendungsnahen Unterdrückungssperren (»shutdown«, »reboot«, »sleep«, »idle«) unterliegen. Systemnahe Unterdrückungssperren (»handle-power-key«, »handle-suspend-key«, »handle-hibernate-key«, »handle-lid-switch«, »handle-reboot-key«) werden immer berücksichtigt, unabhängig von dieser Einstellung.

Diese Einstellungen akzeptieren logische Argumente. Falls »no«, werden von Anwendungen erlangte Unterdrückungssperren respektiert. Falls »yes«, »shutdown«, »reboot«, »sleep« und »idle«, werden Unterdrückungssperren ignoriert. PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited=, HibernateKeyIgnoreInhibited= und RebootKeyIgnoreInhibited= sind standardmäßig »no«. LidSwitchIgnoreInhibited= ist standardmäßig »yes«. Dies bedeutet, dass der Deckelschalter standardmäßig die Unterdrückungssperre nicht berücksichtigt, während das die Einschalt- und Schlaftasten tun, wenn systemd-logind die Ereignisse selbst behandelt (keine systemnahe Unterdrückungssperre durch eine andere Anwendung erlangt ist).

HoldoffTimeoutSec=

Legt eine Zeitdauer nach dem Hochfahren des Systems oder der Systemwiederherstellung fest, in der Systemd nicht auf Deckelereignisse reagieren wird. Dies wird für das System benötigt, um korrekt alle dynamisch eingesteckten Geräte zu erkennen, so dass Systemd Deckelereignisse ignorieren kann, falls externe Monitore oder Dockingstationen verbunden werden. Falls auf 0 gesetzt, wird Systemd immer sofort reagieren, möglicherweise bevor der Kernel alle dynamisch eingesteckten Geräte untersucht hat. Dies ist sicher, so lange Ihnen egal ist, dass Systemd Geräte nicht berücksichtigt, die ein- oder ausgesteckt wurden, während das System ausgeschaltet war. Standardmäßig 30s.

RuntimeDirectorySize=

Setzt die Größenbegrenzung des Laufzeitverzeichnisses $XDG_RUNTIME_DIR für jeden Benutzer, der sich anmeldet. Akzeptiert eine Größe in Bytes, optional mit den gewöhnlichen Endungen K, G, M und T zur Basis 1024 (IEC). Alternativ kann ein numerischer Prozentwert mit Endung »%« angegeben werden, der die Größenbegrenzung relativ zu der Menge des physischen Arbeitsspeichers setzt. Standardmäßig 10%. Beachten Sie, dass diese Größe nur eine Sicherheitsbegrenzung ist. Da jedes Laufzeitverzeichnis ein Tmpfs-Dateisystem ist, wird es nur so viel Speicher wie benötigt verbrauchen.

RuntimeDirectoryInodesMax=

Setzt die Begrenzung der Anzahl der Inodes des Laufzeitverzeichnisses $XDG_RUNTIME_DIR für jeden Benutzer, der sich anmeldet. Akzeptiert eine Nummer, optional mit den gewöhnlichen Endungen K, G, M und T zur Basis 1024 (IEC). Standardmäßig RuntimeDirectorySize= geteilt durch 4096. Beachten Sie, dass diese Größe nur eine Sicherheitsbegrenzung ist. Da jedes Laufzeitverzeichnis ein Tmpfs-Dateisystem ist, wird es nur so viel Speicher wie benötigt verbrauchen.

InhibitorsMax=

Steuert die maximale Anzahl an gleichzeitig erlaubten Hemmern. Standardmäßig 8192 (8K).

SessionsMax=

Steuert die maximale Anzahl an gleichzeitig zu verwaltenden Benutzersitzungen. Standardmäßig 8192 (8K). Abhängig davon, wie das Modul pam_systemd.so in der PAM-Stapel-Konfiguration aufgenommen ist, werden weitere Anmeldesitzungen entweder abgelehnt oder erlaubt, aber von Systemd-logind nicht verfolgt.

RemoveIPC=

Steuert, ob zum Benutzer gehörende System-V- und POSIX-IPC-Objekte entfernt werden sollen, wenn sich der Benutzer komplett abmeldet. Akzeptiert ein logisches Argument. Falls aktiviert, kann der Benutzer, nachdem die letzte seiner Sitzungen beendet wurde, keine IPC-Ressourcen mehr verbrauchen. Dies deckt System-V-Semaphoren, gemeinsam benutzten Speicher und Nachrichtenwarteschlangen, sowie POSIX gemeinsamer Speicher und Nachrichtenwarteschlangen ab. Beachten Sie, dass IPC-Objekte des Benutzers root und anderer Systembenutzer von den Auswirkungen dieser Einstellung ausgenommen sind. Standardmäßig »yes«.

SIEHE AUCH

systemd(1), systemd-logind.service(8), loginctl(1), systemd-system.conf(5)

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.

systemd 247