JulienB
9. November 2022 um 14:06
1
Hallo zusammen,
Leute, ich habe ein Problem!
/var/lib/gladysassistant:/var/lib/gladysassistant
/Pfad zu meinem Disk-Volume/gladysassistant:/var/lib/gladysassistant
Habt ihr eine Idee?
Danke euch!
VonOx
9. November 2022 um 17:52
2
Hmm
const { PlatformNotCompatible } = require('../../utils/coreErrors');
/**
* @description Compute basePath in host and container from mounted point or give default ones.
* @returns {Promise} Base path in host/container to store files.
* @example
* const { basePathOnContainer, basePathOnHost } = await getGladysBasePath();
*/
async function getGladysBasePath() {
let basePathOnContainer = '/var/lib/gladysassistant';
// Fetch container path mount
if (process.env.SQLITE_FILE_PATH) {
const base = process.env.SQLITE_FILE_PATH;
basePathOnContainer = base.substring(0, base.lastIndexOf('/'));
}
// Find mount linked to this path to fetch host path
let currentContainerId;
try {
currentContainerId = await this.getGladysContainerId();
} catch (e) {
afficher l'original
Ich werde versuchen, es zu reproduzieren. Auf welcher Architektur bist du?
Kannst du deine compose/stack posten?
JulienB
9. November 2022 um 21:08
3
Hallo und danke für deine Hilfe!
Hier ist mein compose:
version: "3.3"
services:
gladys:
image: gladysassistant/gladys:v4
container_name: gladys
restart: always
network_mode: host
privileged: true
environment:
NODE_ENV: production
SQLITE_FILE_PATH: /var/lib/gladysassistant/gladys-production.db
SERVER_PORT: "5425"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /var/lib/gladysassistant:/var/lib/gladysassistant
#- ${ROOT}/gladysassistant:/var/lib/gladysassistant
- /dev:/dev
Ich habe auch meine Variable ROOT für die .db in SQLITE_FILE_PATH verwendet.
Architektonisch bin ich auf einem ESXi, das einen OpenMediaVault hostet, auf dem Docker installiert ist.
Das war’s!
Für mich ist die Umgebungsvariable SQLITE_FILE_PATH, die festlegt, welcher Pfad verwendet werden soll.
@JulienB Ich weiß nicht, ob du das GitHub-Ticket und den Pull Request erstellt hast, aber es gibt tatsächlich ein Problem in diesem Teil, wenn docker-compose verwendet wird. Also, es liegt nicht an dir, wir unterstützen docker-compose derzeit nicht gut
Das GitHub-Ticket:
ouvert 06:28PM - 10 Nov 22 UTC
fermé 11:47AM - 15 Nov 22 UTC
**Describe the bug**
When running Docker Gladys with docker compose every time … the container is restarted the MQTT configuration doesn't load (although is still saved in the database).
**To Reproduce**
Steps to reproduce the behavior:
1. With a docker compose file like this:
```yml
# docker-compose.yml
version: "3.3"
services:
gladys:
restart: always
privileged: true
network_mode: host
container_name: gladys
environment:
- NODE_ENV=production
- SERVER_PORT=8090
- TZ=Europe/Madrid
- SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
- "${LOCAL_DATA_DIR}/gladys:/var/lib/gladysassistant"
- "/dev:/dev"
- "/run/udev:/run/udev:ro"
image: "gladysassistant/gladys:v4"
mosquitto:
restart: always
container_name: mosquitto
image: eclipse-mosquitto:2
volumes:
- ${LOCAL_DATA_DIR}/mosquitto/config/:/mosquitto/config/
- ${LOCAL_DATA_DIR}/mosquitto/log/:/mosquitto/log/
- ${LOCAL_DATA_DIR}/mosquitto/data:/mosquitto/data/
ports:
- 1883:1883
- 9001:9001
```
3. Go to `<gladys-server-domain>/dashboard/integration/device/mqtt/setup`
4. Setup the Broker URL to `mqtt://localhost`
5. Everything should work fine
6. Restart the Gladys container
7. Go to `<gladys-server-domain>/dashboard/integration/device/mqtt/setup`
8. The Broker URL is lost
**Expected behavior**
It should keep loading the Broker URL after restart.
**Your Gladys installation (please complete the following information):**
- Raspberry Pi 4
- Debian GNU/Linux 11 (bullseye)
- Docker version 20.10.20, build 9fdeb9c
**Additional context**
When restarting the Docker container this logs are shown:
```
<warn> service.start.js:44 (Service.start) Unable to start service zigbee2mqtt PlatformNotCompatible [Error]: DOCKER_CGROUP_CONTAINER_ID_NOT_AVAILABLE
at System.getGladysContainerId (/src/server/lib/system/system.getGladysContainerId.js:45:13)
at System.getNetworkMode (/src/server/lib/system/system.getNetworkMode.js:16:25)
at Zigbee2mqttManager.init (/src/server/services/zigbee2mqtt/lib/init.js:18:23)
at Object.start (/src/server/services/zigbee2mqtt/index.js:17:5)
at Service.start (/src/server/lib/service/service.start.js:33:7)
```
After some research I found [this Stackoverflow entry](https://stackoverflow.com/questions/68816329/how-to-get-docker-container-id-from-within-the-container-with-cgroup-v2) which lead me to verify that `/proc/self/cgroup` is actually empty.
The issue can be solved when running docker using the `--cid` or `--cgroupns` flag, but none of those options is available in docker compose.
Der Pull Request, der den Fehler behebt:
master ← magarcia:fix/get-container-id
ouvert 07:15PM - 10 Nov 22 UTC
### Pull Request check-list
To ensure your Pull Request can be accepted as fa… st as possible, make sure to review and check all of these items:
- [x] If your changes affects code, did your write the tests?
- [x] Are tests passing? (`npm test` on both front/server)
- [x] Is the linter passing? (`npm run eslint` on both front/server)
- [x] Did you run prettier? (`npm run prettier` on both front/server)
- [ ] If you are adding a new features/services, did you run integration comparator? (`npm run compare-translations` on front)
- [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to [the community](https://community.gladysassistant.com/) for testing before merging.
- [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code)
- [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com).
- [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com).
NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open.
### Description of change
This PR fixes #1647, when `/proc/self/cgroup` doesn't contain the container ID it tries to get it from `/proc/self/mountinfo`.
@VonOx Was denkst du über den Pull Request?
JulienB
11. November 2022 um 16:31
7
pierre-gilles:
Ich weiß nicht, ob du das GitHub-Issue und den Pull Request erstellt hast, aber es gibt tatsächlich ein Problem in diesem Teil, wenn docker-compose verwendet wird. Also, es liegt nicht an dir, aktuell unterstützen wir docker-compose nicht gut
Nein, das war nicht ich! Aber ich werde mich darum kümmern! Danke.
JulienB
11. November 2022 um 16:34
8
HAHA ich hatte den vor 22 Stunden erstellten Issue nicht gesehen! Das hätte tatsächlich ich sein können!
VonOx
11. November 2022 um 18:26
9
Das ist sehr wahrscheinlich damit verbunden
@JulienB Der Fix ist live in Gladys Assistant v4.12.2
Salut à tous,
Je viens de publier v4.12.2, une petite mise à jour qui corrige un bug pour les utilisateurs de docker-compose, désormais l’ID du container est correctement récupéré ce qui permet d’utiliser avec docker-compose les intégrations qui lancent des containers comme l’intégration Zigbee2mqtt par exemple !
Ce fix est la première contribution (#1648 ) d’un utilisateur espagnol, qu’on remercie pour sa première contribution ici .
Comment mettre à…
Das ist nicht normal, der Code holt den Bind, der für Gladys konfiguriert ist.