Docker-ContainerUpdate Pi-Hole schlägt fehlt

[MissErfolg]

Hallo zusammen!

Ich versuche gerade zum ersten Mal unter DSM7 meinen pi-hole Docker-Container upzudaten. Dazu bin ich wie folgt vorgegangen.

1) Neusten pi-hole Container unter "Registrierung" herunterladen
2) Container stoppen
3) Container "zurücksetzen"
4) Container starten

Docker Container wurde unerwartet beendet...

Log:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying...
[fix-attrs.d] 01-resolver-resolv: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 20-start.sh: executing...
/start.sh: line 57: /root/ph_install.sh: No such file or directory
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

Früher (unter DSM6) hat das genauso immer funktioniert. Hat sich da etwas geändert? Oder ist irgendetwas mit dem pi-hole Update nicht in Ordnung.

Zum Glück hatte ich vorher eine Kopie angelegt

Hat schon jmd heute das Update gefahren?

 

[haydibe]

/start.sh: line 57: /root/ph_install.sh: No such file or directory

Image kaputt Unwahrscheinlich das es ein DSM7 Problem ist (wie soll das überhaupt gehen?)

 

[MissErfolg]

OK, dann warte ich mal auf eine neueres Image.

Ich dachte schon, ich sei zu blöd das hinzubekommen.

 

[haydibe]

Hmmm, evtl. doch kein Image Defekt... Es kann an der wundervollen "Zurücksetzen" Funktion von Syno-UI liegen, die alle Parameter des vorherigen Containers übernimmt in den neuen Container übernimmt. Genau so macht es Portainer auch. Für Portainer gibt es einen Issue mit derselben Fehlermeldung auf Github: siehe https://github.com/pi-hole/docker-pi-hole/issues/895.

 

[MissErfolg]

Oha... das könnte sein. Ich beobachte den Thread mal und schaue, was sich so ergibt.

thx für den Hinweis.

 

[haydibe]

Kannst ja den alten Container exportieren, eine Kopie der exportierten json-Datei anlegen und dann in der Kopie die ENV-Einstellungen rausschmeissen die nicht von dir kommen und dann die veränderte Kopie wieder importieren. Wäre spannend, wenn man wüsste welcher Parameter sich da geändert hat...

Update: die unterschiede kannst Du dir selbst ansehen:

docker image inspect pihole/pihole:latest --format '{{json .ContainerConfig.Env}}' | jq

Und dasselbe dann nochmal für das alte Image. Dort pihole/pihole:latest mit der ImageId ersetzen. Die beiden Ausgaben kannst Du dann vergleichen, dann weisst Du welche Variablen sich geändert haben.

Das von heute:

[
"PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PIHOLE_ARCH=amd64",
"S6OVERLAY_RELEASE=https://github.com/just-containers/s6-overlay/releases/download/v2.1.0.2/s6-overlay-amd64.tar.gz",
"PIHOLE_INSTALL=/etc/.pihole/automated install/basic-install.sh",
"PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf",
"PHP_ERROR_LOG=/var/log/lighttpd/error.log",
"IPv6=True",
"S6_LOGGING=0",
"S6_KEEP_ENV=1",
"S6_BEHAVIOUR_IF_STAGE2_FAILS=2",
"ServerIP=0.0.0.0",
"FTL_CMD=no-daemon",
"DNSMASQ_USER=root",
"VERSION=v5.8.1"
]

[
"PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PIHOLE_ARCH=amd64",
"S6OVERLAY_RELEASE=https://github.com/just-containers/s6-overlay/releases/download/v2.1.0.2/s6-overlay-amd64.tar.gz",
"PIHOLE_INSTALL=/root/ph_install.sh",
"PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf",
"PHP_ERROR_LOG=/var/log/lighttpd/error.log",
"IPv6=True",
"S6_LOGGING=0",
"S6_KEEP_ENV=1",
"S6_BEHAVIOUR_IF_STAGE2_FAILS=2",
"ServerIP=0.0.0.0",
"FTL_CMD=no-daemon",
"DNSMASQ_USER=root",
"VERSION=v5.3.1"
]

Man sieht das sich neben VERSION, vor allem der PIHOLE_INSTALL Pfad geändert hat. Einfach im Export die beiden Variablen löschen oder durch die aktuellen ersetzen und dann neu importieren.

 

[MissErfolg]

Ich habe es so gemacht, wie der Kollege im pi-hole Forum geschrieben hat.

Folgende Variablen gelöscht:

• PIHOLE_INSTALL=/root/ph_install.sh
• PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf
• PHP_ERROR_LOG=/var/log/lighttpd/error.log
• S6_LOGGING=0
• S6_KEEP_ENV=1
• S6_BEHAVIOUR_IF_STAGE2_FAILS=2

PIHOLE_INSTALL wird dann beim nächsten Start automatisch geändert auf: /etc/.pihole/automated install/basic-install.sh

Die anderen gelöschten Variablen werden neu angelegt und auf die alten Werte gesetzt.

Pi-hole rennt jetzt in der neuen Version.

EDIT:
Danke für Deine erweiterte Erklärung. Wieder etwas dazugelernt

 

[haydibe]

Top! Lag im Endeffekt an PIHOLE_INSTALL.

 

[ReCyCleR0815]

Hi und ja die Information das der Installationspfad geändert werden muss, war der Schlüssel auch für mich. Alle anderen werden brauchen NICHT gelöscht werden

Also einfach Nach dem Download des "last update" und dem duplizieren des Container bzw. nach dem zurücksetzen des Container diesen bearbeiten und bei
PIHOLE_INSTALL = /etc/.pihole/automated install/basic-install.sh

eintragen dann sollte alles wieder gehen in der Neuen Version!

Grüße

 

[stulpinger]

wär es gerne visuell hat:

https://www.youtube.com/watch?v=4CmUxnsQsfU&t=601s

 

[Tillerbach]

Hallo zusammen,

kann es sein, dass es mit dem Upgrade auf 04.2022 wieder ein Problem gibt? Nach dem Update von 01.2022 startet der Container nicht mehr.

Viele Grüße
Peter

 

[Der Paul]

Je nachdem, wie Du Deinen Container konfiguriert hast, kann es in der Tat zu Problemen kommen (Stichwort: DHCP & Capabilities). Diese sollten aber mit 2022.4.2 behoben sein

 

[Tillerbach]

Danke für die schnelle Antwort. Allerdings, weder latest, 2022.4.2 noch 2022.4.2beta starten. :-(

 

[haydibe]

Beim letzten mal waren es Environment-Variablen die das Problem waren. Die Syno-UI behält die Werte für die Environment-Variablen einfach bei, egal ob diese Default-Werte des Images waren oder von dir gesetzte.

Die neuen sehen folgendermaßen aus:

me@dsm:~$ docker image inspect pihole/pihole:latest --format '{{json .Config.Env}}' | jq
[
  "PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  "phpver=php",
  "PIHOLE_DOCKER_TAG=2022.04.2",
  "S6_OVERLAY_VERSION=v2.1.0.2",
  "PIHOLE_INSTALL=/etc/.pihole/automated install/basic-install.sh",
  "PHP_ENV_CONFIG=/etc/lighttpd/conf-enabled/15-fastcgi-php.conf",
  "PHP_ERROR_LOG=/var/log/lighttpd/error.log",
  "IPv6=True",
  "S6_LOGGING=0",
  "S6_KEEP_ENV=1",
  "S6_BEHAVIOUR_IF_STAGE2_FAILS=2",
  "ServerIP=0.0.0.0",
  "FTL_CMD=no-daemon",
  "DNSMASQ_USER=pihole"
]

Entweder pflegst Du jetzt die fehlenden Variablen nach und löscht die die nicht mehr gebraucht werden (viel Aufwand) oder versuchst das was @MissErfolg geschrieben hat und löscht einfach alle Variablen (hier bin ich überrascht das das überhaupt funktioniert hat).

Oder Du exportierst die Konfiguration von deinem jetzigen Container, editierst die Datei und löscht dabei alle ENV-Variablen die nicht von dir stammen und importierst das ganze wieder.

 

[haydibe]

Seit 5.8.1 hat sich beispielsweise folgendes geändert:


Daraus kann man ableiten, dass
- folgende Environment-Variablen gelöscht werden können: PIHOLE_ARCH, S6OVERLAY_RELEASE, VERSION (ist evtl. irrelevant, da im Zweifel einfach gar nicht mehr benutzt)
- folgende Environment-Variablen neu hinzugefügt werden müssen: phpver, PIHOLE_DOCKER_TAG, S6_OVERLAY_VERSION (ist evtl. automatisch schon passiert?)
- für folgende Environment-Variable muss der Wert geändert werden: DNSMASQ_USER

 

[Tillerbach]

Vielen Dank für die schnelle Hilfe. Ich habe meine .jason-Datei im Editor angepasst, leider ohne Erfolg. Der Container schmiert, nach wie vor, sofort ab. :-(

"env_variables" : [
      {
         "key" : "BLOCK_ICLOUD_PR",
         "value" : "False"
      },
      {
         "key" : "PATH",
         "value" : "/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
      },
      {
         "key" : "phpver",
         "value" : "php"
      },
      {
         "key" : "PIHOLE_DOCKER_TAG",
         "value" : "2022.04.1"
      },
      {
         "key" : "S6_OVERLAY_VERSION",
         "value" : "v2.1.0.2"
      },
      {
         "key" : "PIHOLE_INSTALL",
         "value" : "/etc/.pihole/automated install/basic-install.sh"
      },
      {
         "key" : "PHP_ENV_CONFIG",
         "value" : "/etc/lighttpd/conf-enabled/15-fastcgi-php.conf"
      },
      {
         "key" : "PHP_ERROR_LOG",
         "value" : "/var/log/lighttpd/error.log"
      },
      {
         "key" : "IPv6",
         "value" : "True"
      },
      {
         "key" : "S6_LOGGING",
         "value" : "0"
      },
      {
         "key" : "S6_KEEP_ENV",
         "value" : "1"
      },
      {
         "key" : "S6_BEHAVIOUR_IF_STAGE2_FAILS",
         "value" : "2"
      },
      {
         "key" : "ServerIP",
         "value" : "192.168.0.102"
      },
      {
         "key" : "FTL_CMD",
         "value" : "no-daemon"
      },
      {
         "key" : "DNSMASQ_USER",
         "value" : "pihole"
      },
      {
         "key" : "DNSMASQ_LISTENING",
         "value" : "local"
      },
      {
         "key" : "WEBPASSWORD",
         "value" : "*password*"
      },
      {
         "key" : "WEB_PORT",
         "value" : "*port*"
      }
   ],

 

[luddi]

@Tillerbach Was steht denn in dem log File des Docker Containers? Gibt es darin keine verwertbare Information?

 

[haydibe]

Sehe ich auch so, ohne genaue Fehlermeldung kommt man hier nicht weiter.

Auch wenn ich nicht denke das es ein Problem ist: bei PIHOLE_DOCKER_TAG hast Du 2022.04.1 statt 2022.04.2 verwendet.
Die Werte für die Environment-Variablen sehen soweit plausibel aus - wobei ich die zusätzliche vergebenen Variablen nicht beurteilen kann.

Für Testzwecke würde ich den Container mal ausschalten und auf die Volumes auf andere Host-Verzeichnisse stellen, um sicher zu gehen, dass es kein Problem mit der vorhandenen Konfiguration ist. Kann ja auch sein das sqlite3 db von pihole einen Schlag weg hat - zumindest bei mir hat das damals immer nur zur Fehlerhaften Darstellung der Statistiken geführt, aber nie den Start verhindert... vielleicht ist das mittlerweile anders?

 

[Tillerbach]

Darf ich fragen wo ich das log finde?

Er zerbricht an den Einstellungen zum Netzwerk. Ich habe die Standardeinstellungen exportiert und lediglich meine Netzwerkeinstellungen geändert und neu importiert. Breits mit diesen Änderungen lässt dich der Absturz provozieren:

{
         "key" : "ServerIP",
         "value" : "192.168.0.102"
      },

"network" : [
      {
         "driver" : "host",
         "name" : "host"
      }
   ],
   "network_mode" : "host",
   "port_bindings" : [],

 

[haydibe]

Darf ich fragen wo ich das log finde?

In der Syno-Docker UI -> Container -> dort den Container auswählen, dann oben den Button "Details" -> dort Reiter "Protokoll"

Für andere angenehmer zu lesen ist es, wenn man über ssh sudo docker logs <container name oder id> ausgeben lässt und das Ergebnis dann hier pastet.