BEZEICHNUNG

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

ÜBERSICHT

           /etc/systemd/logind.conf
           /run/systemd/logind.conf
           /usr/local/lib/systemd/logind.conf
           /usr/lib/systemd/logind.conf
           /etc/systemd/logind.conf.d/*.conf
           /run/systemd/logind.conf.d/*.conf
           /usr/local/lib/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 gesetzt. Daher wird eine Konfiguration nur
       benötigt, wenn von diesen Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei wird aus einem
       der aufgeführten Verzeichnisse in der Prioritätsreihenfolge geladen, nur die zuerst gefundene Datei wird
       verwandt: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. Die
       Lieferantenversion der Datei enthält die Vorgaben als auskommentierte Hinweise für den Administrator.
       Lokal können diese Einstellungen durch die Erstellung von Ergänzungen, wie nachfolgend beschrieben, außer
       Kraft gesetzt werden. Zu diesem Zweck kann die Hauptkonfigurationsdatei (oder eine Kopie in /etc/, falls
       sie in /usr/ ausgeliefert wird) auch bearbeitet werden, allerdings wird empfohlen, Ergänzungen für lokale
       Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verändern.

       Zusätzlich zu der Hauptkonfigurationsdatei, werden Ergänzungs-Konfigurationsschnipsel aus
       /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese
       Ergänzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen diese 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, die als letztes in der Sortierung folgt,
       Vorrang, falls mehrere Dateien die gleiche Option angeben. Bei Optionen, die eine Liste von Werten
       akzeptieren, werden Einträge gesammelt, wie sie in den sortierten Dateien auftauchen.

       Wenn Pakete die Konfiguration anpassen müssen, können sie Ergänzungen unter /usr/ installieren. 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. Um Ergänzungen der Pakete
       außer Kraft zu setzen, müssen Ergänzungen verwandt werden, da die Hauptkonfigurationsdatei die niedrigste
       Priorität hat. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl
       und einen Bindestrich voranzustellen, um die Sortierung zu vereinfachen. Dies definiert auch ein Konzept
       von Ergänzungsprioritäten, um es Betriebssystemlieferanten zu ermöglichen, Ergänzungen in einem
       bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte
       das Risiko reduzieren, dass eine Paketergänzung versehentlich durch Benutzer definierte Ergänzungen außer
       Kraft setzt. Es wird empfohlen, den Bereich 10-40 für Ergänzungen in /usr/ und den Bereich 60-90 für
       Ergänzungen in /etc/ und /run/ zu verwenden um sicherzustellen, dass lokale und flüchtige Ergänzungen
       Priorität gegenüber Ergänzungen haben, die vom Betriebssystemlieferanten geliefert werden.

       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.

           Hinzugefügt in Version 190.

       KillUserProcesses=
           Akzeptiert ein logisches Argument. Konfiguriert, ob der Prozess eines Benutzers getötet werden soll,
           wenn sich der Benutzer abmeldet. Falls true, werden die der Sitzung entsprechende Bereichs-Unit und
           alle im Bereich befindlichen Prozesse beendet. Falls nicht true, 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«, »sleep« 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.

           Hinzugefügt in Version 198.

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

           Hinzugefügt in Version 198.

       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.

           Hinzugefügt in Version 240.

       SleepOperation=
           Akzeptiert eine Liste von Schlaf-Operationen. Mögliche Werte sind »suspend«, »hibernate«,
           »hybrid-sleep« und »suspend-then-hibernate«. Steuert die Kandidaten-Schlaf-Operation für die Aktion
           »sleep«. Wird die Aktion »sleep« ausgeführt, dann werden die angegebenen Schlaf-Operation in einer
           festen Reihenfolge geprüft (»suspend-then-hibernate« → »hybrid-sleep« → »suspend« → »hibernate«) und
           die erste, von der Maschine unterstützte wird verwandt, um das System in den Schlafzustand zu
           bringen. Standardmäßig »suspend-then-hibernate suspend hibernate«.

           Hinzugefügt in Version 256.

       HandlePowerKey=, HandlePowerKeyLongPress=, HandleRebootKey=, HandleRebootKeyLongPress=,
       HandleSuspendKey=, HandleSuspendKeyLongPress=, HandleHibernateKey=, HandleHibernateKeyLongPress=,
       HandleLidSwitch=, HandleLidSwitchExternalPower=, HandleLidSwitchDocked=, HandleSecureAttentionKey=
           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«, »sleep«, »lock«, »factory-reset« und »secure-attention-key« sein. Falls
           »ignore«, wird systemd-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= ist standardmäßig »suspend«, HandleHibernateKey= ist standardmäßig »hibernate«,
           HandlePowerKeyLongPress= ist standardmäßig »ignore«, HandleRebootKeyLongPress= ist standardmäßig
           »poweroff«, HandleSuspendKeyLongPress= ist standardmäßig »hibernate«, HandleHibernateKeyLongPress=
           ist standardmäßig »ignore«. HandleLidSwitch= ist 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«. 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. HandleSecureAttentionKey= ist standardmäßig »secure-attention-key«.

           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-key«) 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, außer für
           HandleSecureAttentionKey=, die seit ihrer Ergänzung in v257 immer gehandhabt wird.

           Hinzugefügt in Version 184.

       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).

           Hinzugefügt in Version 190.

       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.

           Hinzugefügt in Version 220.

       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.

           Hinzugefügt in Version 211.

       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.

           Hinzugefügt in Version 246.

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

           Hinzugefügt in Version 230.

       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.

           Hinzugefügt in Version 230.

       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«.

           Hinzugefügt in Version 212.

       StopIdleSessionSec=
           Legt eine Zeitüberschreitung in Sekunden oder eine Zeitspanne fest, nachdem systemd-logind(8) den
           Leerlaufstatus aller Sitzungen überprüfen wird. Jede Sitzung, die länger als die Zeiteüberschreitung
           im Leerlauf ist, wird gestoppt. Beachten Sie, das diese Option nicht für »greeter«- oder
           »lock-screen«-Sitzungen gilt. Standardmäßig »infinity« (unendlich, systemd-logind(8) prüft den
           Leerlaufstatus von Sitzungen nicht). Für Details über Zeitspannen, siehe systemd.time(7).

           Hinzugefügt in Version 252.

       DesignatedMaintenanceTime=
           Legt ein Standard-Kalenderereignis für geplante Herunterfahren fest. Wird daher z.B.. der Befehl
           shutdown -r zum Neustart des Systems ohne Angabe einer Zeitüberschreitung angegeben, würde Logind
           stattdessen das konfigurierte Kalenderereignis verwenden. Zu Details über die Syntax von
           Kalenderereignissen, siehe systemd.time(7).

           Hinzugefügt in Version 257.

SIEHE AUCH

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

ANMERKUNGEN

        1. 💣💥🧨💥💥💣  Bitte  beachten  Sie,  dass  diese Konfigurationsdateien zu allen Zeiten verfügbar sein
           müssen. Falls /usr/local/ eine separate Partition ist, könnte diese während des  frühen  Systemstarts
           nicht verfügbar sein und darf dann nicht für Konfiguration verwandt werden.

Ü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: debian-l10n-german@lists.debian.org.

systemd 257.6                                                                                     LOGIND.CONF(5)