Containers blijven herstarten #171

Tralapo · 2021-02-09T17:43:14Z

Setup/Architecture information

Raspberry Pi 3B, Raspbian

Version of the Docker image

Configuration

### DSMR Database en Reader ###
  dsmrdb:
    image: postgres:12-alpine
    container_name: dsmrdb
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./data/dsmrdb:/var/lib/postgresql/data
    environment:
      - TZ=Europe/Amsterdam
      - PG_TZ=Europe/Amsterdam
      - POSTGRES_USER=dsmrreader
      - POSTGRES_PASSWORD=dsmrreader
      - POSTGRES_DB=dsmrreader

  dsmr:
    image: xirixiz/dsmr-reader-docker:latest
    container_name: dsmr
    depends_on:
      - dsmrdb
    cap_add:
      - NET_ADMIN
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./data/dsmr_backups:/dsmr/backups
    environment:
      - DJANGO_TIME_ZONE=Europe/Amsterdam
      - VIRTUAL_HOST=localhost
    ports:
      - 7777:80
      - 7779:443
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0

Describe the bug

Gebruik deze setup al maanden naar volle tevredenheid, maar gisteren ging het ineens mis.
Zoals gebruikelijk wilde ik alles update door een docker-compose pull en daarna een docker-compose up -d, niets bijzonders zou je zeggen. Ook niets gewijzigd aan de compose-file.

Maar sinds die actie, doen zowel de DSMR als DSMRDB container niets anders dan elke 15-20 seconden opnieuw opstarten, tot op een punt dat de load op de Raspberry zo hoog wordt dat 'ie helemaal niets meer doet.

Heb geprobeerd de database te verwijderen en opnieuw op te tuigen zoals beschreven in de README, maar dat lukt niet eens omdat dsmrdb niet lang genoeg up blijft.

pi@raspberrypi:[~] sudo docker exec -t dsmrdb dropdb dsmrreader -U dsmrreader
dropdb: error: could not connect to database template1: FATAL:  the database system is starting up

pi@raspberrypi:[~] sudo docker exec -t dsmrdb dropdb dsmrreader -U dsmrreader
OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: read init-p: connection reset by peer: unknown

pi@raspberrypi:[~] sudo docker exec -t dsmrdb dropdb dsmrreader -U dsmrreader
dropdb: error: could not connect to database template1: FATAL:  the database system is starting up

Ik heb echt geen flauw idee waar dit ineens vandaan komt of waar ik een oplossing moet zoeken, kan ook niet wijs worden uit de logs:

Debug log

In de log van dsmr zie ik inderdaad terug dat hij niet kan connecten met de database


[ FAIL ] Could not connect to database server. Exiting...
[ INFO ] Removing existing PID files...
[ INFO ] Creating log directory...
[ INFO ] Fixing /dev/ttyUSB* security...
[ INFO ] Verifying if the DSMR web credential variables have been set...
[ INFO ] Verifying Database connectivity...
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: could not connect to server: Connection refused
        Is the server running on host "dsmrdb" (172.18.0.2) and accepting
        TCP/IP connections on port 5432?


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/dsmr/manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 401, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 395, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 330, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 371, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/shell.py", line 87, in handle
    exec(options['command'])
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/db/utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 219, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 200, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 187, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: could not connect to server: Connection refused
        Is the server running on host "dsmrdb" (172.18.0.2) and accepting
        TCP/IP connections on port 5432?

[ FAIL ] Could not connect to database server. Exiting...

De log for dsmrdb geeft (heel vaak) het volgende, met een gekke timestamp

PostgreSQL Database directory appears to contain a database; Skipping initialization

1970-04-29 13:25:44.010 CET [1] LOG:  starting PostgreSQL 12.5 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 32-bit
1970-04-29 13:25:44.010 CET [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
1970-04-29 13:25:44.010 CET [1] LOG:  listening on IPv6 address "::", port 5432
1970-04-29 13:25:44.010 CET [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
1970-04-29 13:25:44.010 CET [22] FATAL:  the database system is starting up
1970-04-29 13:25:44.010 CET [1] LOG:  startup process (PID 21) was terminated by signal 11: Segmentation fault
1970-04-29 13:25:44.010 CET [1] LOG:  aborting startup due to startup process failure
1970-04-29 13:25:44.010 CET [1] LOG:  database system is shut down

The text was updated successfully, but these errors were encountered:

xirixiz · 2021-02-09T18:48:34Z

Kan je eens proberen de postgres:12 image te gebruiken. De afgelopen tijd krijg ik vaker meldingen binnen over de Posgres Alpine image. Verder zie ik de melding:

PostgreSQL Database directory appears to contain a database; Skipping initialization

Heb je de versie van Postgres bijgewerkt of gebruik je 12 al een tijd? Je kan ook alles stoppen en ./data/dsmrdb leegmaken, en vervolgens alles weer starten.

Tralapo · 2021-02-09T19:33:55Z

Nee, ik heb de versie niet gewijzigd. Die had ik altijd al op postgres:12-alpine staan. De appears to contain a database-melding was waarschijnlijk omdat ik dus probeerde om de database te droppen en een
backup terug te zetten. Maar de container bleef niet eens lang genoeg actief om die acties uit te voeren.

Inmiddels heb ik hem omgezet naar postgres:12 zoals je vroeg en daarna blijven beide containers goed draaien!

Nu alleen nog een manier vinden om de data terug te zetten... heb eerst de originele ./data/dsmrdb map teruggezet, daar een databasedump van gemaakt en toen de stappen gevolgd die in de readme staan voor het wijzigen van een Postgres versie en te restoren. Dat restoren lijkt ook goed te gaan. Maar dan krijg ik dit in DSMR:

Geen gegevens gevonden. Zorg ervoor dat het dsmr_datalogger-proces draait of dat je gegevens aanlevert via die API. Daarnaast hoort het dsmr_backend-proces eveneens te draaien.

Tralapo · 2021-02-09T19:48:35Z

In het mapje ./data/dsmr_backups vond ik keurige .sql.gz backups per dag (duh), dus heb die van zondag nu teruggezet en alles werkt weer perfect!

Toch vreemd dat postgres:12-alpine dan ineens zoveel problemen kan veroorzaken.

Tralapo · 2021-02-10T09:55:10Z

DSMR lijkt toch niet helemaal ongeschonden uit de strijd gekomen te zijn. Op het eerste gezicht leek het goed, omdat hij de actuele meterstanden gewoon toont.

Maar zoals het nu lijkt voert hij op de achtergrond niets uit. Er zijn geen live-grafieken en ook geen dag/uurtotalen van na gisteravond. Ook niet als ik die geplande processen via de interface laat uitvoeren.

Op de Status-pagina staan ook de volgende foutmeldingen, waarbij de teller steeds oploopt:

Te veel onverwerkte telegrammen: 16741   (2 dagen, 6 uur geleden)
Dagstatistieken lopen achter   (2 dagen, 10 uur geleden)

De log zegt het volgende:

2021-02-10 10:46:39,946 INFO spawned: 'dsmr_backend' with pid 2738
2021-02-10 10:46:40,951 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-02-10 10:46:59,031 INFO exited: dsmr_backend (exit status 0; expected)
2021-02-10 10:47:00,043 INFO spawned: 'dsmr_backend' with pid 2739
2021-02-10 10:47:01,047 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-02-10 10:47:17,468 INFO exited: dsmr_backend (exit status 0; expected)
2021-02-10 10:47:18,479 INFO spawned: 'dsmr_backend' with pid 2740
2021-02-10 10:47:19,484 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-02-10 10:47:36,522 INFO exited: dsmr_backend (exit status 0; expected)
2021-02-10 10:47:37,533 INFO spawned: 'dsmr_backend' with pid 2741
2021-02-10 10:47:38,539 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-02-10 10:47:54,677 INFO exited: dsmr_backend (exit status 0; expected)
2021-02-10 10:47:55,685 INFO spawned: 'dsmr_backend' with pid 2742
2021-02-10 10:47:56,759 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2021-02-10 10:48:13,702 INFO exited: dsmr_backend (exit status 0; expected)
2021-02-10 10:48:14,709 INFO spawned: 'dsmr_backend' with pid 2743
2021-02-10 10:48:15,713 INFO success: dsmr_backend entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

xirixiz · 2021-02-10T09:58:19Z

@Tralapo dit is meer een DSMR gerelateerde melding, dus niet zo zeer Docker. Wellicht kan @dennissiemensma hierbij assisteren?

dennissiemensma · 2021-02-10T17:53:57Z

@Tralapo ik denk dat je het beste even kunt zoeken naar de specifieke log voor het dsmr_backend proces. Ik verwacht dat daar een betere foutmelding in staat.

Ik weet alleen niet precies waar die logs in de container staan. In de native installatie in /var/log/supervisor/.

Tralapo · 2021-02-10T18:53:30Z

Ik heb even - ./data/dsmr_logs:/var/log/supervisor toegevoegd aan de volumes voor dsmr, zodat de logs opgeslagen worden.

In dsmr_backend.log zie ik het volgende:

[2021-02-10 19:53:42,891] ERROR    CLIENTS: Run error: MQTT: Client no longer connected
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging
[2021-02-10 19:54:01,409] ERROR    CLIENTS: Run error: MQTT: Client no longer connected
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging
[2021-02-10 19:54:18,694] ERROR    (IntegrityError) dsmr_consumption.services.run errored: null value in column "delivered_1" violates not-null constraint
DETAIL:  Failing row contains (393388, 2021-02-08 04:00:00+01, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).

[2021-02-10 19:54:20,645] ERROR    CLIENTS: Run error: MQTT: Client no longer connected
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging
[2021-02-10 19:54:38,807] ERROR    CLIENTS: Run error: MQTT: Client no longer connected
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/v4/troubleshooting.html#logging
[2021-02-10 19:54:57,304] ERROR    (IntegrityError) dsmr_consumption.services.run errored: null value in column "delivered_1" violates not-null constraint
DETAIL:  Failing row contains (393389, 2021-02-08 04:00:00+01, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).

Daarna heb ik de logging op DEBUG ingesteld en krijg ik dit:

[2021-02-10 19:56:16,282] WARNING  MQTT: --- Unexpected disconnect, re-connecting...
[2021-02-10 19:56:16,284] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 16 Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k60) client_id=b'DSMR-reader'
[2021-02-10 19:56:16,303] DEBUG    MQTT: Paho client: on_disconnect(userdata, rc) None 1
[2021-02-10 19:56:16,304] WARNING  MQTT: --- Unexpected disconnect, re-connecting...
[2021-02-10 19:56:16,306] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 16 Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k60) client_id=b'DSMR-reader'
[2021-02-10 19:56:16,344] WARNING  MQTT: Client no longer connected. Signaling restart to reconnect...
[2021-02-10 19:56:16,345] ERROR    CLIENTS: Run error: MQTT: Client no longer connected
[2021-02-10 19:56:16,364] WARNING  Detected backend restart required, stopping process...
[2021-02-10 19:56:16,364] INFO     dsmr_backend.management.commands.dsmr_backend: [i] Detected StopInfiniteRun exception
[2021-02-10 19:56:16,364] INFO     dsmr_backend.management.commands.dsmr_backend: Exiting on next run...
[2021-02-10 19:56:16,365] DEBUG    dsmr_backend.management.commands.dsmr_backend: Sleeping 10.0s
[2021-02-10 19:56:26,367] DEBUG    CLIENTS: Terminating 1 client(s)
[2021-02-10 19:56:26,368] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 16 Sending DISCONNECT
[2021-02-10 19:56:26,370] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 8 failed to receive on socket: [Errno 32] Broken pipe
[2021-02-10 19:56:26,371] DEBUG    MQTT: Paho client: on_disconnect(userdata, rc) None 0
[2021-02-10 19:56:26,372] DEBUG    dsmr_backend.management.commands.dsmr_backend: Exited
[2021-02-10 19:56:33,340] DEBUG    MQTT: Initializing MQTT client for "192.168.1.20:1883"
[2021-02-10 19:56:33,342] DEBUG    MQTT: Using insecure connection (no TLS)
[2021-02-10 19:56:33,345] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 16 Sending CONNECT (u0, p0, wr0, wq0, wf0, c1, k60) client_id=b'DSMR-reader'
[2021-02-10 19:56:33,354] DEBUG    INFLUXDB: Integration disabled in settings (or due to an error previously)
[2021-02-10 19:56:33,355] DEBUG    Persistent clients initialized: [<class 'paho.mqtt.client.Client'>]
[2021-02-10 19:56:33,355] DEBUG    dsmr_backend.management.commands.dsmr_backend: Starting infinite command loop...
[2021-02-10 19:56:33,364] DEBUG    SP: 1 backend service(s) ready to run
[2021-02-10 19:56:33,365] DEBUG    SP: Running "Generate consumption data" (dsmr_consumption.services.run)
[2021-02-10 19:56:33,673] ERROR    (IntegrityError) dsmr_consumption.services.run errored: null value in column "delivered_1" violates not-null constraint
DETAIL:  Failing row contains (393391, 2021-02-08 04:00:00+01, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).

[2021-02-10 19:56:33,819] DEBUG    SP: Rescheduled "Generate consumption data" to 2021-02-10 19:57:03.674270+01:00 (ETA 0:00:29.854980)
[2021-02-10 19:56:34,601] DEBUG    CLIENTS: Running 1 active client(s)
[2021-02-10 19:56:34,613] INFO     MQTT: Processing 5 message(s)
[2021-02-10 19:56:34,614] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 16 Sending PUBLISH (d0, q0, r1, m1), 'b'dsmr/reading/electricity_currently_delivered'', ... (5 bytes)
[2021-02-10 19:56:34,615] DEBUG    MQTT: Paho client: on_log(userdata, level, buf) None 8 failed to receive on socket: [Errno 32] Broken pipe
[2021-02-10 19:56:34,615] DEBUG    MQTT: Paho client: on_disconnect(userdata, rc) None 1

dennissiemensma · 2021-02-10T19:35:37Z

Ik zie twee meldingen:

IntegrityError
MQTT-error (failed to receive on socket: [Errno 32] Broken pipe)

Het kan zijn dat de tweede een gevolg is van de eerste, maar dat weet ik niet zeker. De eerste lijkt aan te geven dat er een meting is met alleen een datumtijd, maar dat lijkt me vreemd en heb ik niet eerder gezien.

Ik denk dat je het beste even in de admin-interface kan kijken op /admin/dsmr_datalogger/dsmrreading/ en eentje openen om te zien of de velden daar ook allemaal leeg zijn.

Tralapo · 2021-02-10T19:46:35Z

Er zijn 114 pagina's met un-processed lezingen daar en heb hier en daar steekproeven gedaan, maar ze zien er allemaal heel normaal uit. Zeker niet leeg.

dennissiemensma · 2021-02-11T07:12:52Z

Toevallig meldt iemand een soortgelijk issue via: dsmrreader/dsmr-reader/issues/1282

Weet je nog wat voor soort backup je hebt teruggezet? Was dat een volledige of een partial?
En kwam die backup van dezelfde DSMR-reader versie?

Tralapo · 2021-02-11T07:18:48Z

Zaterdag heb ik (zoals ik vaker doe) al m'n containers geüpdate, waarna de problemen begonnen.

Daarna heb ik, zoals hierboven besproken, de postgres-versie gewijzigd en via onderstaande methode één van de dagelijkse backups die DSRM zelf maakt teruggezet, die van vlak voor ik ging updaten.

Het is dus inderdaad wel zo dat de backup uit een oudere versie van DSMR komt dan de huidige.

docker-compose stop dsmr
docker exec -t dsmrdb dropdb dsmrreader -U dsmrreader
docker exec -t dsmrdb createdb -O dsmrreader dsmrreader -U dsmrreader
cat dsmrreader.sql | docker exec -i dsmrdb psql -U dsmrreader
docker-compose start dsmr

dennissiemensma · 2021-02-11T17:05:19Z

Oke ik denk dat je dan het beste even dat issue in DSMR-reader kan volgen.

dennissiemensma · 2021-02-11T22:16:36Z

@xirixiz ter debugging en vergelijking, wat zijn jouw resultaten als je dit uitvoert in je DSMR DB container:

grep timezone /var/lib/postgresql/data/postgresql.conf

En gebruik je env vars voor instellen tijdzone van de DSMR DB? Bijvoorbeeld:

  dsmrdb:
    environment:
      - TZ=Europe/Amsterdam
      - PG_TZ=Europe/Amsterdam

xirixiz · 2021-02-12T06:32:27Z

De output is dan:

-> docker exec -ti dsmrdb bash
bash-5.1# grep timezone /var/lib/postgresql/data/postgresql.conf
log_timezone = 'Europe/Amsterdam'
timezone = 'Europe/Amsterdam'

Verder zet ik alleen TZ=Europe/Amsterdam op zowel de PG als DSMR container. That's it. Ik zal ook eens even meekijken met het issue dat open staat, wellicht kan ik daar nog hulp bieden.

Belangrijke toevoeging is nog dat ik /etc/localtime mount in de container. Dus de timezone in de container komt in feite van mijn host af.

MRL-33 · 2021-02-14T15:27:01Z

Ik loop ook steeds tegen deze foutmeldingen aan.
Nu heb ik alle containers/netwerken gestopt en verwijderd. (docker-compose down) Ook heb ik de submappen dsmr_backup & dsmrdb verwijderd.
Daarna heb alles weer opgestart met docker-compose pull & docker-compose up -d, maar krijg nog steeds een foutmelding in portainer.
`1970-05-02 03:22:16.010 CET [21] FATAL: the database system is starting up

1970-05-02 03:22:16.010 CET [1] LOG: startup process (PID 20) was terminated by signal 11: Segmentation fault

1970-05-02 03:22:16.010 CET [1] LOG: aborting startup due to startup process failure

1970-05-02 03:22:16.010 CET [1] LOG: database system is shut down`

Wat moet ik doen om alles te verwijderen?

Tralapo · 2021-02-14T18:39:27Z

Heb je geprobeerd om postgres:12.4-alpine als database in te stellen? Dat loste alles uiteindelijk op voor mij. Zie ook deze issue.

MRL-33 · 2021-02-14T21:57:32Z

Heb je geprobeerd om postgres:12.4-alpine als database in te stellen? Dat loste alles uiteindelijk op voor mij. Zie ook deze issue.

Het ziet er naar uit dat jou voorstel de oplossing is! Dankjewel.
@xirixiz: Kan je dit ook duidelijk(er) opnemen/vermelden in jou docker-compose.yaml voor DSMR-reader?

xirixiz · 2021-02-15T07:15:52Z

Had ik al gedaan afgelopen week :)

Tralapo closed this as completed Feb 9, 2021

xirixiz mentioned this issue Feb 10, 2021

OperationalError: FATAL: #169

Closed

dennissiemensma mentioned this issue Feb 11, 2021

⚠️ Docker only - Reading timestamp differences (1 or 2 hours off) dsmrreader/dsmr-reader#1282

Closed

dennissiemensma mentioned this issue Feb 21, 2021

Te veel onverwerkte telegrammen: 226 (over 33 minuten) #174

Closed

dennissiemensma mentioned this issue May 10, 2021

Datalogger telegram processing loopt precies 1 minuut achter? dsmrreader/dsmr-reader#1383

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Containers blijven herstarten #171

Containers blijven herstarten #171

Tralapo commented Feb 9, 2021

xirixiz commented Feb 9, 2021

Tralapo commented Feb 9, 2021 •

edited

Loading

Tralapo commented Feb 9, 2021

Tralapo commented Feb 10, 2021

xirixiz commented Feb 10, 2021

dennissiemensma commented Feb 10, 2021

Tralapo commented Feb 10, 2021 •

edited

Loading

dennissiemensma commented Feb 10, 2021

Tralapo commented Feb 10, 2021

dennissiemensma commented Feb 11, 2021

Tralapo commented Feb 11, 2021

dennissiemensma commented Feb 11, 2021

dennissiemensma commented Feb 11, 2021

xirixiz commented Feb 12, 2021 •

edited

Loading

MRL-33 commented Feb 14, 2021

Tralapo commented Feb 14, 2021 •

edited

Loading

MRL-33 commented Feb 14, 2021

xirixiz commented Feb 15, 2021

Containers blijven herstarten #171

Containers blijven herstarten #171

Comments

Tralapo commented Feb 9, 2021

Setup/Architecture information

Version of the Docker image

Configuration

Describe the bug

Debug log

xirixiz commented Feb 9, 2021

Tralapo commented Feb 9, 2021 • edited Loading

Tralapo commented Feb 9, 2021

Tralapo commented Feb 10, 2021

xirixiz commented Feb 10, 2021

dennissiemensma commented Feb 10, 2021

Tralapo commented Feb 10, 2021 • edited Loading

dennissiemensma commented Feb 10, 2021

Tralapo commented Feb 10, 2021

dennissiemensma commented Feb 11, 2021

Tralapo commented Feb 11, 2021

dennissiemensma commented Feb 11, 2021

dennissiemensma commented Feb 11, 2021

xirixiz commented Feb 12, 2021 • edited Loading

MRL-33 commented Feb 14, 2021

Tralapo commented Feb 14, 2021 • edited Loading

MRL-33 commented Feb 14, 2021

xirixiz commented Feb 15, 2021

Tralapo commented Feb 9, 2021 •

edited

Loading

Tralapo commented Feb 10, 2021 •

edited

Loading

xirixiz commented Feb 12, 2021 •

edited

Loading

Tralapo commented Feb 14, 2021 •

edited

Loading