mikael
Janvier 13, 2022, 5:36
1
Bonjour,
J’ai pas trouver de opic parlant de çà mais un bouton pour arrêter/redemarrer proprement le raspberry depuis gladys serait un plus.
Je pense qu’il aurait sa place au niveau du menu système pour les administrateurs.
J’ai rapidement vu que c’était possible d’éteindre l’hôte depuis un docker mais j’ai pas fait le test.
Fabic
Janvier 13, 2022, 8:00
3
Sinon :
Ouvrir un terminal (“cmd” dans la barre de recherche sous windows ou ctrl+alt+T sous linux)
ssh pi@ip-de-gladys
mdp du pi (raspberry la première fois)
sudo shutdown now
guim31
Janvier 13, 2022, 9:18
4
Ce qui est un peu moins user friendly il faut l’avouer haha
mikael
Janvier 14, 2022, 9:07
5
petite précision lorsque l’on se connecte la première fois il demande le changement de mot de passe du compte pi.
Je demande çà car Gladys est dans une démarche user friendly. c’est comme si dans windows on te disait de taper la commande shutdown /s à chaque fois pour arrêter ton pc.
C’est juste que des fois mon raspberry est arrêté de façon brutale car mon pc est pas forcément allumer.
Après c’est pas une feature a développer en urgence car pour la majorité nous savons aller sur un système linux et l’arrêter proprement.
Je suis 100% d’accord avec toi, dans la v4 la principale philosophie c’est « pas de CLI, pas de SSH ».
cce66
Décembre 28, 2022, 5:53
7
Salut @pierre-gilles
Il y a une possibilité d’avoir un cron sur le pi qui lance un script disons toute les secondes
ce script peut crée dans Gladys puis copié dans le système local
26 commandes Docker les plus courantes avec exemples partie 19
A partir de là n’importe quelle commande peut-être exécutée (arret/redemarrage etc) depuis le container Gladys dans le système local, il faut juste au démarrage avoir un script qui supprimes le script envoyé depuis Gladys précédemment !
Il serait même possible d’avoir un retour d’état avec exec dans le script 26 commandes Docker les plus courantes avec exemples partie 7 il suffit de faire une création de fichier dans le docker avec la commande qui va bien !
VonOx
Décembre 28, 2022, 7:48
8
C’est une idée effectivement, cependant trop risqué pour moi, il suffit que le/les scripts ne soit pas supprimé et on redemarre en boucle.
Dans tous les cas ont est en mode serveur, le besoin de stop restart est quasi nul.
Seul cas un update de kernel, dans ce cas c’est toi qui le fait manuellement et donc peut redémarrer.
cce66
Décembre 28, 2022, 8:05
9
il y a la possibilité de limiter le nombre de fois ou le script peut-être exécuté via une limite par timestamp dans le nom du script par exemple ou mieux via crontab non ? Donc un crontab toute les secondes qui surveille un script envoyé depuis Gladys, dans le script il y la 1ère commande crontab à exécuter ainsi pas de risque de boucle et on peut avoir un log qui peut être analysé par une 2de commande crontab du script précédent qui lui peut générer un retour via un crontab qui génère une commande dans le container Gladys. Bref de quoi faire interagir Gladys avec son environnement…cela pourrait même être intégrable dans Gladys avec les scénarios !
VonOx
Décembre 28, 2022, 8:09
10
Je penses que le plus propre pour l’hote c’est de passer par dbus, il y’a un package nodejs de dispo.
Côté Gladys on pourra vérifier que dbus est dispo dans le conteneur, et si c’est le cas d’afficher le/les boutons. Et oui pourquoi pas avoir aussi dans les scenes une action dispo.
https://www.freedesktop.org/wiki/Software/systemd/dbus/
Et dans ce cas on limite les risques.
cce66
Décembre 30, 2022, 10:23
11
Quelle que soit la solution ce serait un vrai plus pour l’utilisateur lambda de pouvoir arrêter son système proprement (pour une question de maintenance par exemple) sans passer par une connexion ssh pas user-friendly ! Je connais pas dbus, il marcherait aussi sur d’autre plate-forme que PI et/ou sous windows ?
Lokkye
Juillet 24, 2026, 2:18
12
J’ai (Claude :)) commencé à faire une implémentation simple en utilisant dbus.
Il faut que je fasse les tests sur mon installation avec le docker mais c’est en bonne voie.
Lokkye
Juillet 24, 2026, 7:31
13
Tester sur mon MiniPC sous debian
Les PRs qui vont bien:
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.
Merci pour la PR
Je t’ai fais un retour :
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.
Tu peux demander à Claude de me répondre