- Bearbeitet
Schau doch mal wie Plasma bzw. Lxqt sich verhält wenn du es über Konsole startest.
Der Login-Manager macht etwas mehr als nur die GUI hochfahren.
Schau doch mal wie Plasma bzw. Lxqt sich verhält wenn du es über Konsole startest.
Der Login-Manager macht etwas mehr als nur die GUI hochfahren.
Wenn ich sddm umgehe scheint es zumindest mit LxQt zu funktionieren, bekomme aber dort keine Rückmeldung des inhibit status. Wenn ich das hier richtig verstehe scheint es ein Bug in sddm zu sein.
Ich weiß nicht welchem Zweck deine Tests dienen sollen, aber du könntest dabei auch mal andere Login-Manager ausprobieren oder je nach dem auch ganz darauf verzichten und das Login auf tty1 vorgehmen.
Der Zweck ist schnell erklärt, ich bin auf der suche nach einem Tool mit dem root Ausschalten, Neustarten und Tiefschlaf unterbinden kann. In einem anderen Thread, von mir, ist mir zu systemd-inhibit geraten worden.
Anderen Login-Manager oder Login auf tty1 möchte ich eigentlich nicht, bin froh das die Leute mit dem jetzt Zustand zurechtkommen. Problem ist halt das mir das System schon mehrmals während einer SSH-Session runter gefahren worden ist, ist beim Update sehr ärgerlich.
Du versuchst mittels Fernwartung ein System zu aktualisieren, während der Benutzer dir den Rechner abschaltet. Das ist natürlich nicht so günstig.
Ohnehin, solltest du ihm vorher Bescheid sagen, sonst zieht er morgen noch den Netzstecker raus, wenn er was nicht versteht.
Eine andere Möglichkeit anstatt systemd-inhibit
wäre es während der Wartungsarbeiten die Usersitzung zu beenden dann kann er keine Buttons mehr anklicken. Aus der Ferne müsste das so gehen.
loginctl list-sessions
loginctl terminate-session <Nr>
Und da gäbe es auch noch dies hier 😉
notify-send "Dein Rechner wird gerade aktualisiert-Bitte nicht Herunterfahren oder Neustarten!"
https://man.archlinux.org/man/notify-send.1.en
Ein Script für notify-send das den Benutzer darüber informiert, das ich per Fernwartung drauf zugreife habe ich schon. Einige Leute ignorieren die Meldung leider, aber einfach die Usersitzung killen will ich auch nicht.
Noch eine Idee, jedoch noch recht unfertig.
Plasma spricht über dbus mit systemd. Dafür sind spezielle services definiert z.B. gibt es den /usr/share/dbus-1/services/org.kde.Shutdown.Service und den /usr/share/dbus-1/services/org.freedesktop.systemd1.service.
Wenn es dir gelingt für die Dauer deiner ssh Sitzung diese services stillzulegen dann kann dein User über die GUI das System auch nicht mehr herrunterfahren.
Wahrscheinlich werden Änderungen aber erst wirksam wenn du dann auch dbus neu startest.
Gerade mal mit LXDM und LightDM ausprobiert, genau das selbe wie bei SDDM. Bei aktiven systemd-inhibit auf tty4, kann der Benutzer zwar nicht direkt aus der Sitzung eine Neustart usw machen, er landet in der Loginmaske, aber daraus ist eine Neustart ohne Probleme möglich.
Bin wieder bei "ich verstehe es nicht"
Funktioniert das Tool denn bei euch? Muss dafür noch irgendwas konfiguriert werden oder sollte es per default-config funktionieren?
@tuxnix
P.S. Danke für die Idee, aber irgendwie möchte ich doch systemd-inhibit zum laufen bringen, nagt an mir.
Andy@Arch Bin wieder bei "ich verstehe es nicht"
Funktioniert das Tool denn bei euch? Muss dafür noch irgendwas konfiguriert werden oder sollte es per default-config funktionieren?
Bei meinem kurzen Test ist es ähnlich wie bei dir.
Es ist - wie so vieles in Poetterings Universum - ggf. technisch gut gedacht, aber nicht konsequent.
Zuviele (D)Busse+PAMs+KITs machen IMHO alles undurchsichtig und kompliziert.
Mein Vorschlag: Versuche nicht soziale Probleme (Reboot trotzt angekündigter Wartung) mittels unzulänglicher Werkzeuge zu lösen. Wenn den Betreffenden das Problem nicht klar ist, dann stelle die Wartung ein oder hinterlasse mal (testweise) ein nichtbenutzbares System ("Das habt ihr nun von eurem Reboot/Ausschalten").
Ansonsten bliebe @tuxnix Vorschlag, die user-session zu locken/pausieren, daß hilft aber nicht gegen erzwungenen Poweroff/Reboot.
Beim Test kam ich dann weiter:
Wenn root den dbus.service stoppt. Dann ist bei mir kein (Software)-Reboot mittels DisplayManager/Windowmanager-Reboot-Option mehr möglich. Das Arbeiten für den User ist dann ggf. nur rudimentär möglich (der user-dbus ist ja auch funktionsuntüchtig). Es ist dann auch ein Aus/Wiedereinloggen des Users nötig nach einem Neustart des system-dbus.
Alles suboptimal...
//Edit:
Ich hatte (alles zusätzlich zu systemd-inhibit) auch nochmal den Ansatz versucht, diverse shutdown/reboot Services+Targets während der "Wartung" zu maskieren, um Reboot-Versuche zu unterbinden. Bin aber auch nicht wesentlich weiter gekommen (auch aus Mangel an Interesse).
Es müßte (und das müßte dann wohl im Kernel-Ring angesiedelt sein) etwas adäquates zu z.B: pam_nologin geben, also im wesentlichen: Existiert eine Datei z.B. /etc/noreboot dann funktioniert nur noch der physikalische Weg. Im Zuge dieses noreboot dürften dann logischerweise auch keine vorhergehenden Units (umount etc) versucht werden.
Mein Ansatz wäre wohl:
Ich erstelle für wichtige Dinge ein eigenes Wartungs.target und boote für die Wartung in dieses target/runlevel. Dort kann dann zum sshd ein X/Wayland oder wie auch immer gestartet sein mit deutlichem Hinweis(-Bild, feh z.B.) das Wartung läuft, nicht ausschalten usw.
Kein User == Kein Problem <g>
@GerBra hat völlig recht.
Für zwischenmenschliche Missverständnisse gibt es keine Softwarelösung.
Vielleicht hilft es wenn du langsam machst. Damit gibst du der anderen Seite die Gelegenheit etwas von dir zu wollen.
Was hältst du von Debian?
Damit entfällt das Problem des häufigen updates.
Zwischenmenschliche Missverständnisse hin oder her, meiner Meinung nach ist das Ding (systemd inhibit) dafür gemacht einen unerwartete Reboot, Shutdown usw zu verhindern.
Wollte da jetzt auch mal einen Bugreport schreiben, kann mich leider nicht mehr im Archbugtracker anmelden. Läuft so ein Account nach 5 Jahren Inaktivität ab?
Andy@Arch Den Bugtracker von vor 5 Jahren gibt es nicht mehr.
Sind denn die Konto vom alten Bugtracker migriert worden?
Andy@Arch Sind denn die Konto vom alten Bugtracker migriert worden?
Nein, du müsstest dich neu registrieren, was aber lt. Hinweis auf der Seite zur Zeit nicht möglich ist, bzw. nur per Mail an accountsupport@archlinux.org
Ich bezweifele aber, dass der Arch-Bugtracker überhaupt der richtige Adressat ist, weil in deren Zuständigkeit nur Kompilierungs- oder Paketierungsfehler fallen, aber keine Programmfehler; die müsstest du Upstream direkt bei den Entwicklern melden. Wobei du erst einmal genau klären müsstest, in welcher der Systemkomponenten der Fehler tatsächlich auftritt.
Um auszuschließen, dass es sich um ein Arch-Problem handelt, könntest du dasselbe mal mit einer anderen Distribution testen (kein Arch-Derivat). Wenn bei gleichem Versionsstand das Problem da auch auftritt, ist es mit ziemlicher Sicherheit ein Programmproblem, tritt es dort nicht auf, könnte man mit den Informationen das Problem an die Arch-Emtwickler melden.
Andy@Arch ...meiner Meinung nach ist das Ding (systemd inhibit) dafür gemacht einen unerwartete Reboot, Shutdown usw zu verhindern. Wollte da jetzt auch mal einen Bugreport schreiben...
Das folgende dürfte dazu interessant sein:
https://www.man7.org/linux/man-pages/man5/logind.conf.5.html
A different application may disable logind's handling of
system power and sleep keys and the lid switch by taking a
low-level inhibitor lock ("handle-power-key",
"handle-suspend-key", "handle-hibernate-key",
"handle-lid-switch", "handle-reboot-key"). This is most
commonly used by graphical desktop environments to take over
suspend and hibernation handling, and to use their own
configuration mechanisms. If a low-level inhibitor lock is
taken, logind will not take any action when that key or
switch is triggered and the Handle*= settings are irrelevant.
Auch interssant:
https://www.freedesktop.org/wiki/Software/systemd/inhibit/
https://man.archlinux.org/man/extra/man-pages-de/loginctl.1.de
Ich hab mir erstmal die deutschsprachige Manpage rausgesucht siehe hier.
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«, »lock« und »factory-reset« 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.
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.
Wenn ich das richtig verstehe behandelt das die Hardwaretasten und nicht die Softwaretaste in einem DE oder DM.
Es bietet aber eine Erklärung für das beobachtete Verhalten. Auch wenn ich die Logik dahinter nicht verstehe, dachte bisher das Linux hierarchisch aufgebaut ist. Befehl von DE => Systemd => Linux Kernel und umgekehrt Output von Linux Kernel => Systemd => DE.
Wenn jetzt das DE an Systemd vorbei das Kommando direkt an den Kernel weiterreicht, ist das irgendwie kontraproduktiv, denn das System wird doch mit Systemd administriert. Oder habe ich da einen Denkfehler?
Wie dem auch sei praktisch bring mich das jetzt auch nicht weiter.
Andy@Arch Es bietet aber eine Erklärung für das beobachtete Verhalten.
Also vielleicht doch kein bug!
Andy@Arch Wenn jetzt das DE an Systemd vorbei das Kommando direkt an den Kernel weiterreicht, ist das irgendwie kontraproduktiv, denn das System wird doch mit Systemd administriert. Oder habe ich da einen Denkfehler?
Der user muss normaler weise auch sein System runterfahren können und das tut er für gewöhnlich über die DE.
@tuxnix das soll er auch tun dürfen, aber in der hierarchisch Reihenfolge DE => Systemd => Linux Kernel. Und wenn ich als Bofh Systemd sage du darfst nicht runterfahren dann soll das auch nicht passieren.
Ich weiß das der Linux Desktop eine Randerscheinung ist, und das Linux Server mit WinVMs verbreiteter sind, aber was machen denn Admins mit einigen Hundert oder mehr Linux Systemen? Updaten und Beten das keiner die Kiste ausmacht kann ja keine Lösung sein.
Ich kenne jetzt deinen genauen Use case nicht. Ich hab Updates mal eine zeitlang damit erschlagen:
https://github.com/ch3paz/update-on-boot/tree/master
Ist Overkill und sicher nicht schön, funktioniert aber ganz leidlich. Nachteil: wenn man den reboot erzwingt kann es einem User die Session unterm Hintern wegziehen 🙂 Und manchmal muss man halt Dinge von Hand nachziehen.