Closed hoorna closed 2 years ago
Hi, interessant issue! Zelf gebruik ik geen compose maar alleen docker run. Zelf heb ik ook een Synology (vergelijkbare setup dus) en kan het dus goed nabootsen. Kan je ook de content can jouw docker-compose file delen wellicht?
Het is iig consistent, ook zonder docker-compose
[
{
"Id": "1f34900267beb9e74f9265de6e06908c6be2bf083d8c9af40f32038da8e3d694",
"Created": "2021-12-10T09:53:08.578646447Z",
"Path": "/bin/bash",
"Args": [
"-c",
"/app/run.sh"
],
"State": {
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 137,
"Error": "",
"StartedAt": "2021-12-10T09:53:11.20986239Z",
"FinishedAt": "2021-12-15T19:51:46.029109133Z",
"StartedTs": 1639129991,
"FinishedTs": 1639597906
},
Ik weet wel waar het mee te maken heeft. Dat heeft te maken met de manier waarop de applicatie gestart wordt in de Docker container. Er wordt namelijk gebruik van supervisord om meerdere processen te starten. Oke, het volgt niet heel erg de Docker gedachtengang, maar de details zal ik je besparen.
Ik moet even het eea testen, maar ik denk dat ik dit wel kan oplossen. Er komt dan een nieuwe release van de Docker image, maar zal je daarover dan informeren.
Voor mij klinkt het geruststellend dat je op jouw systeem dezelfde output krijgt als op mijn systeem. ;-). Ik ben benieuwd wat je test oplevert en of je dit issue kunt oplossen.
Onderstaand de inhoud van mijn docker-compose file.
version: '3'
services:
dsmrdb:
image: postgres:13
container_name: dsmrdb
restart: always
volumes:
- /volume1/docker/dsmr-reader/dsmrdb:/var/lib/postgresql/data
environment:
- TZ=Europe/Amsterdam
- PG_TZ=Europe/Amsterdam
- POSTGRES_USER=dsmrreader
- POSTGRES_PASSWORD=dsmrreader
- POSTGRES_DB=dsmrreader
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 10
dsmr:
image: xirixiz/dsmr-reader-docker:latest
depends_on:
dsmrdb:
condition: service_healthy
container_name: dsmr
links:
- dsmrdb:dsmrreader
cap_add:
- NET_ADMIN
restart: always
volumes:
- /volume1/docker/dsmr-reader/dsmrdb_backups:/dsmr/backups
environment:
- TZ=Europe/Amsterdam
- DJANGO_TIME_ZONE=Europe/Amsterdam
- VIRTUAL_HOST=localhost
- DSMRREADER_ADMIN_USER=username
- DSMRREADER_ADMIN_PASSWORD=password
ports:
- 7777:80
Fixed in release 2021.12.01
-> docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a575440236d9 xirixiz/dsmr-reader-docker:latest "/app/run.sh" About a minute ago Exited (0) 4 seconds ago dsmr
De exitcode lijkt met de publicatie van de nieuwe image inderdaad verdwenen maar dat is helaas niet zo. Toen ik na installatie van de nieuwe versie de container stopte kreeg ik inderdaad exitcode 0. Echter na herstarten van de container en wederom stoppen kwam exitcode 137 weer terug.
Vreemd is ook dat -als ik de container via SSH stop- ik in alle gevallen (ook bij de eeste keer stoppen) nog steeds vanuit mijn DiskStation de melding krijg dat de dsmr container onverwacht is gestopt. Het maakt niet uit of ik de container laat stoppen met het docker of met het docker-compose commando.
Hmm, vreemd. Ik vermoed dat het te maken heeft met een state waarin de container zich dan nog bevind en dan weer opnieuw gestart wordt.
De UI vanuit DSM zou ik sowieso niet gebruiken voor Docker, maar dat is persoonlijke voorkeur. Verder zou ik adviseren om een container eigenlijk altijd down te brengen, dus verwijderen. De container is stateless en stoppen/starten is eigenlijk in basis minder betrouwbaar vwb Docker.
Voor nu laat ik het issue even voor wat het is. Waarschijnlijk speelt dit al sinds de eerste release en heeft het verder nooit voor problemen gezorgd. Wanneer ik een keer wat meer tijd heb, dan ga ik dit zeker nog verder onderzoeken.
Bij mij gaat het wel goed nu. Stop je direct na het starten, dus voordat het proces helemaal gestart is? Dan krijg je inderdaad nog steeds een error 137
Stop -> Start -> Stop -> Start -> Stop
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ef567ccb023 xirixiz/dsmr-reader-docker:amd64-development "/app/run.sh" 2 minutes ago Exited (0) 2 seconds ago
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ef567ccb023 xirixiz/dsmr-reader-docker:amd64-development "/app/run.sh" 3 minutes ago Up 6 seconds 0.0.0.0:7777->80/tcp, 0.0.0.0:7778->443/tcp dsmr
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ef567ccb023 xirixiz/dsmr-reader-docker:amd64-development "/app/run.sh" 3 minutes ago Exited (0) 2 seconds ago dsmr
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ef567ccb023 xirixiz/dsmr-reader-docker:amd64-development "/app/run.sh" 4 minutes ago Up 8 seconds 0.0.0.0:7777->80/tcp, 0.0.0.0:7778->443/tcp dsmr
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ef567ccb023 xirixiz/dsmr-reader-docker:amd64-development "/app/run.sh" 4 minutes ago Exited (0) 2 seconds ago dsmr
In release 2021.12.02 heb ik nog wel het volgende toegevoegd wat zou kunnen helpen:
[eventlistener:processes]
command=bash -c "printf 'READY\n' && while read line; do kill -SIGQUIT ${PPID}; done < /dev/stdin"
events=PROCESS_STATE_STOPPED,PROCESS_STATE_EXITED,PROCESS_STATE_FATAL
Issue
Hi,
Al bijna een half jaar heb ik met veel plezier(!) een DSMR docker container draaien op mijn Synology (eerst met DSM 6.2 en later met DSM 7.0.1). DSMR draait fantastisch en zonder problemen. De docker container heb ik aangemaakt en gestart via het docker-compose commando met een docker-compose file.
Er is een issue waarvan ik de oorzaak niet weet. Ik zou het graag willen oplossen omdat ik bang ben dat het een keer problemen gaat veroorzaken in mijn database.
Als ik via SSH de DSMR docker container stop met "docker compose --file docker-compose.yml stop dsmr" dan krijg ik van de Synology DiskStation een melding dat de container onverwachts is gestopt. In de logfile van de dockercontainer kan ik niets bijzonders hierover vinden en DSMR lijkt ook geen problemen te ondervinden. De DSMR container kan met docker-compose gewoon weer worden gestart; DSMR gaat probleemloos verder. Andere docker containers, die ik heb draaien en die ik handmatig met docker-compose stop, genereren deze Synology melding niet.
Wanneer ik in SSH met het commando "docker inspect" informatie opvraag over de gestopte container dan krijg ik onder andere de onderstaande output. Daaruit blijkt dat de container is gestopt met exitcode 137. Uiteraard heb ik op internet informatie gezocht over deze exitcode. De meeste berichten geven aan dat er een probleem zou zijn met de hoeveelheid gealloceerd geheugen en dat in dat geval de status van OOMKilled variabele op "true" zal staan. Dat laatste is bij mij niet geval waaruit ik opmaak dat er geen geheugenprobleem is.
Ik hoop dat iemand weet wat er aan de hand is en hoe de exitcode is op te lossen.
Which version has the issue?
DSMR-reader v4.19
What was the last working version?
No response
What type of installation are you running (architecture)?
Other
Anything in the logs that might be useful?
No response
Additional information
No response