mikael
13. Januar 2022 um 17:36
1
Hallo,
Ich habe kein Thema dazu gefunden, aber ein Button zum sauberen Herunterfahren/Neustarten des Raspberry Pi über Gladys wäre ein Pluspunkt.
Ich denke, er würde sich gut im Systemmenü für Administratoren machen.
Ich habe schnell gesehen, dass es möglich ist, den Host von einem Docker aus herunterzufahren, aber ich habe es nicht getestet.
Fabic
13. Januar 2022 um 20:00
3
Alternativ:
guim31
13. Januar 2022 um 21:18
4
Das ist ein bisschen weniger benutzerfreundlich, das muss man zugeben haha
mikael
14. Januar 2022 um 09:07
5
Eine kleine Präzisierung: Beim ersten Anmelden fordert es die Änderung des Passworts des pi-Kontos.
Ich frage danach, weil Gladys einen benutzerfreundlichen Ansatz verfolgt. Es ist, als würde Windows dich jedes Mal auffordern, den Befehl shutdown /s einzugeben, um den PC herunterzufahren.
Es ist nur so, dass mein Raspberry manchmal abrupt ausgeschaltet wird, weil mein PC nicht unbedingt eingeschaltet ist.
Aber es ist keine Funktion, die dringend entwickelt werden muss, denn die meisten von uns wissen, wie man ein Linux-System aufruft und es ordnungsgemäß herunterfährt.
mikael:
Ich frage das, weil Gladys benutzerfreundlich ist. Es ist so, als würde man in Windows jedes Mal den Befehl shutdown /s eingeben müssen, um den PC herunterzufahren.
Ich bin zu 100% deiner Meinung, in der Version 4 lautet die Hauptphilosophie « keine CLI, kein SSH ».
cce66
28. Dezember 2022 um 17:53
7
Hallo @pierre-gilles 26 commandes Docker les plus courantes avec des exemples Teil 1926 commandes Docker les plus courantes avec des exemples Teil 7 es reicht, eine Datei im Docker mit dem entsprechenden Befehl zu erstellen!
VonOx
28. Dezember 2022 um 19:48
8
Das ist zwar eine Idee, aber für mich zu riskant. Es reicht, wenn die Skripte nicht gelöscht werden und wir in einer Endlosschleife neu starten.
In jedem Fall sind wir im Server-Modus, der Bedarf an Stop-Restart ist quasi null.
Einziger Fall ist ein Kernel-Update. In diesem Fall machst du das manuell und kannst dann neu starten.
cce66
28. Dezember 2022 um 20:05
9
Es gibt die Möglichkeit, die Anzahl der Ausführungen eines Skripts zu begrenzen, z. B. durch eine Zeitstempelbegrenzung im Skriptnamen oder besser über crontab, oder? Also ein crontab alle Sekunden, das ein von Gladys gesendetes Skript überwacht. Im Skript gibt es dann den ersten crontab-Befehl, der ausgeführt werden soll, sodass keine Schleife entsteht. Und man kann ein Log haben, das von einem zweiten crontab-Befehl des vorherigen Skripts analysiert werden kann, der wiederum eine Rückmeldung über einen crontab generieren kann, der einen Befehl im Gladys-Container generiert. Also alles, um Gladys mit seiner Umgebung interagieren zu lassen… Das könnte sogar in Gladys mit den Szenarien integriert werden!
VonOx
28. Dezember 2022 um 20:09
10
Ich denke, das Sauberste für den Host wäre, über dbus zu gehen, es gibt ein verfügbares Node.js-Paket.
Auf Gladys-Seite können wir überprüfen, ob dbus im Container verfügbar ist, und falls ja, die Schaltfläche(n) anzeigen. Und ja, warum nicht auch eine verfügbare Aktion in den Szenen haben.
Und in diesem Fall begrenzen wir die Risiken.
cce66
30. Dezember 2022 um 22:23
11
Egal welche Lösung, es wäre ein echter Vorteil für den durchschnittlichen Nutzer, sein System ordnungsgemäß herunterfahren zu können (z. B. aus Wartungsgründen) ohne eine SSH-Verbindung, die nicht besonders benutzerfreundlich ist! Ich kenne mich mit D-Bus nicht aus, würde es auch auf anderen Plattformen als PI und/oder unter Windows funktionieren?
Lokkye
24. Juli 2026 um 14:18
12
Ich (Claude :)) habe mit einer einfachen Implementierung unter Verwendung von dbus begonnen.
Ich muss die Tests an meiner Docker-Installation durchführen, aber es läuft gut.
Lokkye
24. Juli 2026 um 19:31
13
Testen auf meinem MiniPC unter Debian
Die PRs, die gut laufen:
master ← callemand:feature/reboot-shutdown-host-docs
ouvert 02:43PM - 24 Jul 26 UTC
Documents the new **Reboot / Shutdown host** feature added in GladysAssistant/Gl… adys#2709.
- Add `-v /run/dbus:/run/dbus:ro` to the `docker run` command so the buttons (Settings → System) can reach systemd-logind over the system D-Bus socket.
- Add a "Reboot / Shutdown the host from Gladys" section explaining the requirements (systemd host, `--privileged`, D-Bus socket) and behaviour.
- English (`docs/`) and French (`i18n/fr`) versions.
Companion PR: GladysAssistant/Gladys#2709
🤖 Generated with [Claude Code](https://claude.com/claude-code)
master ← callemand:feature/reboot-shutdown-host
ouvert 02:42PM - 24 Jul 26 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fast… as possible, make sure to review and check all of these items:
- [x] If your changes affect the code, did you write the tests?
- [x] Are server tests passing with coverage? (`cd server && npm run coverage`) — Codecov requires **100% coverage on lines changed in this PR** _(the new functions `rebootHost`/`shutdownHost`/`isHostPowerManagementAvailable` are at 100%; the new controller handlers and the added `getInfos` line are covered too)_
- [x] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed) _(left to CI)_
- [x] Is the linter passing? (`npm run eslint` on both front/server)
- [x] Did you run prettier? (`npm run prettier` on both front/server)
- [x] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front) — en/fr/de complete
- [x] Did you test this pull request in real life? With real devices? _(AMD64 test image being built for a real x86_64 host running systemd)_
- [x] If your changes modify the API (REST or Node.js), did you modify the API documentation? (apidoc `@api` comments added for the two new endpoints)
- [x] If you are adding a new features/services which needs explanation, did you modify the user documentation? See https://github.com/GladysAssistant/v4-website — done in `feature/reboot-shutdown-host-docs` (EN + FR)
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`)? _N/A — no new device/service data, only two admin actions_
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
Adds the ability to **reboot or shut down the host machine** running Gladys (Raspberry Pi, mini-PC…) directly from the **Settings → System** page — a frequently requested feature ([forum](https://community.gladysassistant.com/t/demande-de-mise-en-place-dun-bouton-arret-et-redemarrage-du-raspberry/6786)).
Until now `system.shutdown()` only stopped the Gladys process; there was no way to power off / reboot the underlying host.
**Mechanism.** The two actions talk to `systemd-logind` over the host **system D-Bus socket** (`org.freedesktop.login1` → `Reboot` / `PowerOff`, non-interactive), via `dbus-send`. No new npm dependency; the `dbus` package is added to both Docker images so `dbus-send` is present.
**Backend**
- `system.rebootHost` / `system.shutdownHost`: call systemd-logind through D-Bus.
- `system.isHostPowerManagementAvailable`: best-effort capability check (Linux + `dbus-send` binary + system D-Bus socket), exposed in `getInfos()` as `host_power_management_available`.
- `POST /api/v1/system/reboot` and `POST /api/v1/system/shutdown-host` (authenticated + admin). The command is awaited so failures are returned to the client.
**Frontend** (Settings → System)
- New "Reboot / Shutdown host" card with a **two-step confirmation** (anti-misclick).
- Buttons are **disabled with a tooltip** when the capability is unavailable, and the server error message is surfaced on failure.
- Reboot button is orange (`btn-warning`), Shutdown is red (`btn-danger`), matching the app's button conventions.
- i18n: en / fr / de.
**Docker**
- Install the `dbus` package in `docker/Dockerfile` and `docker/Dockerfile.buildx`.
- Requires the host D-Bus socket mounted: `-v /run/dbus:/run/dbus:ro` (documented in the v4-website PR).
**Behaviour on a standard install**: after a **reboot** the Gladys container comes back thanks to `--restart=always`; after a **shutdown** the machine stays off until powered on manually. If the host is not systemd-based or the socket isn't mounted, the buttons stay disabled.
**Tests**: unit tests for the two host-power functions (D-Bus command + failure propagation), the capability check (Linux/binary/socket matrix), and the two new controller endpoints.
_Screenshots to be added._
## Summary by CodeRabbit
* **New Features**
* Added administrator host power controls in System Settings (reboot and shutdown) with two-step confirmations.
* Added success/error feedback and clear messaging when host power actions are unavailable.
* Added host power availability detection to automatically disable the controls when unsupported.
* Added English, French, and German translations for the host power UI.
* **Bug Fixes**
* Improved user-facing error reporting when host power commands cannot be issued.
* **Chores**
* Updated container images to include the system tooling required for host power requests.
Danke für das PR
Ich habe dir Feedback gegeben:
master ← callemand:feature/reboot-shutdown-host
ouvert 02:42PM - 24 Jul 26 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fast… as possible, make sure to review and check all of these items:
- [x] If your changes affect the code, did you write the tests?
- [x] Are server tests passing with coverage? (`cd server && npm run coverage`) — Codecov requires **100% coverage on lines changed in this PR** _(the new functions `rebootHost`/`shutdownHost`/`isHostPowerManagementAvailable` are at 100%; the new controller handlers and the added `getInfos` line are covered too)_
- [x] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed) _(left to CI)_
- [x] Is the linter passing? (`npm run eslint` on both front/server)
- [x] Did you run prettier? (`npm run prettier` on both front/server)
- [x] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front) — en/fr/de complete
- [x] Did you test this pull request in real life? With real devices? _(AMD64 test image being built for a real x86_64 host running systemd)_
- [x] If your changes modify the API (REST or Node.js), did you modify the API documentation? (apidoc `@api` comments added for the two new endpoints)
- [x] If you are adding a new features/services which needs explanation, did you modify the user documentation? See https://github.com/GladysAssistant/v4-website — done in `feature/reboot-shutdown-host-docs` (EN + FR)
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`)? _N/A — no new device/service data, only two admin actions_
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
Adds the ability to **reboot or shut down the host machine** running Gladys (Raspberry Pi, mini-PC…) directly from the **Settings → System** page — a frequently requested feature ([forum](https://community.gladysassistant.com/t/demande-de-mise-en-place-dun-bouton-arret-et-redemarrage-du-raspberry/6786)).
Until now `system.shutdown()` only stopped the Gladys process; there was no way to power off / reboot the underlying host.
**Mechanism.** The two actions talk to `systemd-logind` over the host **system D-Bus socket** (`org.freedesktop.login1` → `Reboot` / `PowerOff`, non-interactive), via `dbus-send`. No new npm dependency; the `dbus` package is added to both Docker images so `dbus-send` is present.
**Backend**
- `system.rebootHost` / `system.shutdownHost`: call systemd-logind through D-Bus.
- `system.isHostPowerManagementAvailable`: best-effort capability check (Linux + `dbus-send` binary + system D-Bus socket), exposed in `getInfos()` as `host_power_management_available`.
- `POST /api/v1/system/reboot` and `POST /api/v1/system/shutdown-host` (authenticated + admin). The command is awaited so failures are returned to the client.
**Frontend** (Settings → System)
- New "Reboot / Shutdown host" card with a **two-step confirmation** (anti-misclick).
- Buttons are **disabled with a tooltip** when the capability is unavailable, and the server error message is surfaced on failure.
- Reboot button is orange (`btn-warning`), Shutdown is red (`btn-danger`), matching the app's button conventions.
- i18n: en / fr / de.
**Docker**
- Install the `dbus` package in `docker/Dockerfile` and `docker/Dockerfile.buildx`.
- Requires the host D-Bus socket mounted: `-v /run/dbus:/run/dbus:ro` (documented in the v4-website PR).
**Behaviour on a standard install**: after a **reboot** the Gladys container comes back thanks to `--restart=always`; after a **shutdown** the machine stays off until powered on manually. If the host is not systemd-based or the socket isn't mounted, the buttons stay disabled.
**Tests**: unit tests for the two host-power functions (D-Bus command + failure propagation), the capability check (Linux/binary/socket matrix), and the two new controller endpoints.
_Screenshots to be added._
## Summary by CodeRabbit
* **New Features**
* Added administrator host power controls in System Settings (reboot and shutdown) with two-step confirmations.
* Added success/error feedback and clear messaging when host power actions are unavailable.
* Added host power availability detection to automatically disable the controls when unsupported.
* Added English, French, and German translations for the host power UI.
* **Bug Fixes**
* Improved user-facing error reporting when host power commands cannot be issued.
* **Chores**
* Updated container images to include the system tooling required for host power requests.
Du kannst Claude bitten, mir zu antworten
Hallo zusammen!
Dieses Thema ist nun in Entwicklung .
Ein Pull Request wurde eröffnet, um die Host-Stopp- und -Neustart-Buttons in den Systemeinstellungen hinzuzufügen:
master ← claude/resolve-pr-2709-conflicts-fvymxg
ouvert 12:07PM - 24 Aug 26 UTC
### Description
Conflict-resolution branch for #2709 (`callemand:feature/reboot… -shutdown-host`), which had become `dirty` against `master`. This branch is the PR's head merged with the current `master`, with the conflict resolved — the feature itself is unchanged from #2709.
**The conflict**: `front/src/routes/settings/settings-system/SettingsSystemPage.jsx`. Since #2709 was opened, `master` reorganized the System settings page into two thematic columns (system & maintenance on the left — updates, containers, logs, database upkeep; behavior preferences on the right) and added `SettingsSystemKeepDeviceHistory` / `SettingsSystemTimeExpiryState`. #2709 had added its `SettingsSystemHostPower` card to the old flat list.
**Resolution**: keep `master`'s two-column layout intact, and place the host power card at the end of the left (system & maintenance) column, where it belongs thematically. No other file conflicted; the server-side changes (`system.rebootHost` / `system.shutdownHost` / `detectHostPowerManagement`, the two API routes, `getInfos()` fields) merged cleanly.
Verification on the merged tree:
- `npx eslint` on the touched server and front files: no errors (5 pre-existing warnings from #2709, unchanged).
- Prettier: both touched front files match the project style.
- Server tests for the affected areas (`test/lib/system`, `test/controllers/system`): 259 passing.
- `npm run compare-translations` on front: en / fr / de complete.
- `npm run build` on front: succeeds.
If the contributor would rather land the resolution on their own branch, this merge commit can be pushed to `callemand:feature/reboot-shutdown-host` instead and this PR closed.
## Forum
Forum: https://community.gladysassistant.com/t/demande-de-mise-en-place-dun-bouton-arret-et-redemarrage-du-raspberry/6786
### Checklist
- [x] Tests pass: the system lib and controller suites pass on the merged tree (full `npm run coverage` and Cypress left to CI)
- [x] Linter and prettier pass on both front and server
- [x] No undocumented breaking change
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01VrJCRi9if1kC9DVmDcS8sb
---
_Generated by [Claude Code](https://claude.ai/code/session_01VrJCRi9if1kC9DVmDcS8sb)_
## Summary by CodeRabbit
* **New Features**
* Added host reboot and shutdown controls to System Settings.
* Actions now require confirmation and show localized success, error, and unavailable-state messages.
* Availability is detected automatically and displayed based on system support.
* Added English, German, and French translations.
* **Bug Fixes**
* Improved handling of delayed responses and connection loss during power actions.
* Preserved orange button colors in dark mode.
* **Tests**
* Added coverage for power-management detection, execution, error handling, and user-facing controls.
Zögert nicht, dem PR zu folgen, zu testen (optional, vor allem bei kleinen Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.
@Lokkye ich habe es auf meiner Produktion getestet und diese Meldung erhalten:
Ich habe eine klassische Installation (gleicher Docker-Befehl wie auf der Website), also stellt es gut den durchschnittlichen Gladys-Benutzer dar
PS: Ich habe Fable darauf laufen lassen
