mikael
January 13, 2022, 5:36pm
1
Hello,
I haven’t found a topic discussing this, but a button to properly shut down/restart the Raspberry Pi from Gladys would be a plus.
I think it would fit well in the system menu for administrators.
I quickly saw that it was possible to shut down the host from a Docker, but I haven’t tested it.
Fabic
January 13, 2022, 8:00pm
3
Sinon:
guim31
January 13, 2022, 9:18pm
4
What’s a bit less user-friendly, I have to admit haha
mikael
January 14, 2022, 9:07am
5
A small clarification when you connect for the first time, it asks you to change the password for the pi account.
I ask this because Gladys is in a user-friendly approach. It’s as if in Windows you were told to type the command shutdown /s every time to turn off your PC.
It’s just that sometimes my Raspberry Pi is turned off abruptly because my PC is not necessarily on.
After that, it’s not a feature to develop urgently because for the majority of us we know how to go to a Linux system and shut it down properly.
I’m 100% with you, in v4 the main philosophy is « no CLI, no SSH ».
cce66
December 28, 2022, 5:53pm
7
Hi @pierre-gilles 26 commandes Docker les plus courantes avec des exemples partie 19
VonOx
December 28, 2022, 7:48pm
8
That’s indeed an idea, however it’s too risky for me — it’s enough that the script(s) are not deleted and we’ll restart in a loop.
In any case we are in server mode, the need to stop/restart is almost nil.
The only case is a kernel update; in that case you do it manually and can therefore reboot.
cce66
December 28, 2022, 8:05pm
9
There is the possibility of limiting the number of times the script can be executed by using a timestamp-based limit in the script name, for example, or better via crontab, right? So a crontab running every second that watches a script sent from Gladys; in the script there is the 1st crontab command to execute so there’s no risk of a loop, and we can have a log that can be analyzed by a 2nd crontab command of the previous script, which itself can generate a response via a crontab that creates a command in the Gladys container. In short, a way for Gladys to interact with its environment…this could even be integrated into Gladys with scenarios!
VonOx
December 28, 2022, 8:09pm
10
I think the cleanest approach for the host is to use D-Bus (dbus); there’s a Node.js package available.
On the Gladys side we can
cce66
December 30, 2022, 10:23pm
11
Whatever the solution, it would be a real plus for the average user to be able to shut down their system properly (for maintenance purposes, for example) without having to go through an SSH connection that’s not user-friendly! I don’t know D-Bus; would it also work on platforms other than the Raspberry Pi and/or on Windows?
Lokkye
July 24, 2026, 2:18pm
12
I (Claude :)) started a simple implementation using dbus.
I need to run tests on my docker installation, but it’s on the right track.
Lokkye
July 24, 2026, 7:31pm
13
Testing on my MiniPC under Debian
The PRs that are going well:
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)_
- [ ] 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
- [ ] 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.
Thanks for the PR
I gave you some feedback:
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)_
- [ ] 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
- [ ] 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.
You can ask Claude to reply to me
Hi everyone!
This topic is now in development .
A PR has been opened to add the host shutdown and restart buttons in the System settings:
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)_
Feel free to follow the PR, test (optional, especially for small requests) and give your feedback here if needed.
@Lokkye I tested it on my production and got this message:
I have a classic installation (same docker run as on the website), so it represents the average Gladys user
PS: I ran Fable on it
