Hi everyone,
Guys, I have a problem!
I want to install my Gladys instance on my OpenMediaVault. I have a dedicated disk volume and I wanted to install it there from a Portainer stack and therefore with Docker Compose.
I just wanted to change the volume variable:
/var/lib/gladysassistant:/var/lib/gladysassistant
to
/path/to/my/disk/volume/gladysassistant:/var/lib/gladysassistant
but
during the configuration of the Zigbee2mqtt service the containers created by Gladys end up in /var/lib/gladysassistant.
So I tried changing the volumes of these two containers after their creation but it didn’t work.
Any idea?
(For now I’m using the /var/lib/gladysassistant volume and everything’s fine!)
Thanks!
VonOx
November 9, 2022, 5:52pm
2
Hmm That’s not normal, the code retrieves the bind that is configured for Gladys.
/**
* @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
const currentContainerId = await this.getGladysContainerId();
const gladysMounts = await this.getContainerMounts(currentContainerId);
if (gladysMounts) {
const baseMount = gladysMounts.find((mount) => {
return mount.Destination === basePathOnContainer;
});
Ce fichier a été tronqué. afficher l'original
I’ll try to reproduce it. Which architecture are you on?
Can you post your compose/stack?
1 Like
Hi and thanks for your help!
Here is my 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
I had also used my ROOT variable for the .db in the SQLITE_FILE_PATH.
The ROOT variable is: ROOT= /srv/dev-disk-by-uuid-5338eaab-600f-4cba-ba84-cdee7b15fd65/appdata
Architecture-wise I’m on an ESXi that hosts an OpenMediaVault on which Docker is installed.
I had another symptom: none of the configs were being saved; I think there’s a mixup between the two folders.
There you go!
For me it’s the environment variable SQLITE_FILE_PATH that defines which path to use.
Don’t forget that the container runs in privileged mode on the host OS, which can change behavior. For example, Gladys has access to the entire OS, unlike other containers.
@JulienB I don’t know if you were the one who created the GitHub issue and the PR, but there is indeed a problem in this part when docker-compose is used. So it’s not on your side — indeed, we currently don’t support docker-compose very well
The GitHub issue:
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.
The PR that fixes the bug:
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 I’d appreciate your feedback on the PR
JulienB
November 11, 2022, 4:31pm
7
pierre-gilles:
I don’t know if it was you who created the GitHub issue and the PR, but there is indeed a problem with this part when docker-compose is used. So it’s not coming from your side; indeed, at the moment we don’t support docker-compose very well.
Ah no, it’s not me! But I’ll take a look at that! Thanks.
I started working with the default config. I’ll run tests if there’s a solution before reverting to my volume.
@JulienB the fix is 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
Le CHANGELOG complet est disponible ici .
Comment mettre à…
1 Like