unbound startet nicht/stoppt unerwartet

[*kw*]

Hallo,

der Klassiker: "Ich hab' nichts gemacht!"

Tatsache, ich bin letzten Mittwoch in Urlaub, habe vorher noch das DSM-Update auf 7.2.1-69057 gemacht und anschließend nochmal ein Backup durchgeführt. Zu diesem Zeitpunkt lief alles fehlerfrei es wurde (dockerseitig) nichts verändert.

Als ich gestern nach mitten in der Nacht nach Hause kam, meckerte GöGa über fehlendes Internet. Ursache: unbound container inaktiv, Neustart bricht nach wenigen Sekunden ab.

Das Protokoll sagt:



Ich konnte aber unbound weder löschen noch den Container entfernen. Daraufhin den Container Manager komplett mit allen Daten gelöscht/wieder installiert und nur versucht, AdGuard Home und unbound zu installieren (nach meiner Anleitung von EDvS). Auch hier steigt unbound nach wenigen Sekunden wieder aus

Zugegeben, ich bin nicht der "docker-König" und genau aus diesem Grund mache ich jede Nacht zusätzlich ein Hyper-Backup auf einen Stick (10 Versionen). Auch ein Einspielen des zuletzt funktionierenden Standes (03.10.) brachte keine Änderung.

Gab es in meiner (NAS-freien) Abwesenheit irgendwas, was ich verpasst habe?

Danke und Grüße
Oliver

 

[maxblank]

Hi Oliver,
mit dem Update scheint Synology einiges verbockt zu haben. Ob das dein Problem ist, kann ich allerdings nicht mit Sicherheit sagen.

Ich bin froh, dass ich es noch nicht eingespielt habe.

https://www.synology-forum.de/threads/dsm-7-2-1-69057-ist-verfuegbar.128990/

Grüße
maxblank

 

[Benie]

Sehe ich auch so, ich warte auch noch ob da etwas neues kommt.

 

[*kw*]

Na suuuper...

Bisher hatte ich unbound über den Aufgabenplaner installiert, jetzt nochmal manuell über den Container Manager. Auch hier läuft unbound in eine "Neustart-Dauerschleife".

 

[plang.pl]

Versuch mal Folgendes (in dieser Reihenfolge):
-Rechtsklick auf den unbound Ordner unter docker in der FileStation -> Eigenschaften -> für Everyone Read/Write vergeben
->siehe auch in meiner Anleitung Schritt 1
-->testen, ob es wieder startet, wenn nicht:
-unbound in einer älteren Version testen

Dass es am Update seitens Synology liegt, glaube ich nicht. Ich habe da keine Probleme.

 

[*kw*]

Ich war schon geneigt, deine Anleitung Schritt für Schritt durchzugehen, konnte aber beim besten Willen nicht verstehen, weshalb ausschließlich unbound so rumzickt. Wie gesagt (s.o.), ich hatte unbound nur als einzigen Container installiert und das gefiel dem Container Manager schon nicht.

Hatte ich schon erwähnt, dass es gerade an meiner Urlaubserholung zehrt?

Ich test weiter und melde mich.

 

[plang.pl]

Das kriegen wir schon wieder hin.
Ich denke, dass am Error aus deinem Screenshot liegt. Da steht ja "Permission denied". Das hatte ich auch schon - und mit dem Setzen von R/W für everyone war das erledigt

 

[*kw*]

So, ich fühle mich gerade wie 95° Kochwäsche nach 1.400 U/Min...Es geht wieder alles.

Aber nachdem zwischendurch sogar der reverse proxy nicht mehr funktioniert, habe ich nach diversesten (trial'n'error) Versuchen alles wieder zum Laufen bekommen. Letztendlich wurde an den docker & container settings nichts verändert (backups), ich musste "lediglich" händisch die unbound-Version 1.18.0 (=latest) installieren. Die zickte nicht rum und der Container blieb aktiv. Die "latest" ist jedemal wieder ausgestiegen.

Eventuell bleibt noch ein wenig fine tuning...

 

[*kw*]

Eine Sache ist mir gerade aufgefallen: unbound legt bei mir kein docker-Unterverzeichnis "unbound" im FileExplorer an, bzw. im vorher händisch angelegten Ordner steht nichts drin.

Einziger Protokolleintrag im Container:

date                         stream        content
2023/10/10 15:16:43    stdout    [1696943803] unbound[1:0] info: start of service (unbound 1.18.0).
2023/10/10 15:16:43    stdout    [1696943803] unbound[1:0] warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache.
2023/10/10 15:16:43    stdout    [1696943803] unbound[1:0] warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.
2023/10/10 15:16:43    stdout    [1696943803] unbound[1:0] error: Could not open logfile /dev/null: Permission denied

 

[Ulfhednir]

Lässt du zufälligerweise deine Container per Watchtower updaten? Welches Image hast du denn überhaupt im Einsatz?

 

[*kw*]

per Watchtower updaten?

Ja

Welches Image hast du denn überhaupt im Einsatz?

1.18.0, was laut github die aktuellste ist. Der als „latest“ gekennzeichnete Container läuft gar nicht.

 

[plang.pl]

Bei mir hat unbound die noch nie von selbst angelegt, Ich musste Files immer selbst anlegen

 

[*kw*]

Ich habe das Ganze mal auf github gepostet und von Matthew Vance folgende Antwort erhalten:

The differences between 1.18.0 and latest are the changes between 60f9d11 and 84088be. The big differences are latest uses Debian Bookworm as the base, OpenSSL 3.1.3 (instead of 3.1.2), and sets the following in the default config:

• ede: yes
• ede-serve-expired: yes
• harden-unknown-additional: yes
• sock-queue-timeout: 3

I'm not seeing any issues with the default config running on Ubuntu 22.04.3. I don't have a Synology to test on. While it doesn't make sense, my suspicion is Synology isn't getting along with the update to Debian Bookworm. Out of curiosity, does another image based on Debian Bookworm work without issue?

 

[plang.pl]

Da ist vielleicht wieder das Thema mit dem veralteten Kernel interessant.
Hatten wir hier gestern erst wieder

 

[*kw*]

Weitere Antwort von mvance auf die Frage eines anderen Nutzers (Kernel-Anpassung):

I do not intend to go back. That's not been confirmed as the issue. If it is, it would be better if Synology updated their system to support Debian Bookworm based containers. Staying on old versions will eventually create security issues.

[edit]: Frage mich, ob ich erstmal auf unbound verzichten sollte?

 

[plang.pl]

Ich würde deshalb nicht darauf verzichten. Bzw. würde ich wenn überhaupt, nur darüber nachdenken, dass nicht auf einer DS laufen zu lassen.
Zur Not tut es ja auch eine schlanke virtuelle Maschine mit Ubuntu-Server oder lubuntu als Docker Host und all die Problemchen sind verschwunden

 

[*kw*]

Ich betreibe die DS ausschließlich lokal. Auch dann nicht? Bin froh, den ganzen Docker-Kram per Händchenhalten installiert bekommen zu haben.

 

[Tuxnet]

DSM 7.2.1-69057 Update 1 Ist freigegen

 

[*kw*]

@Tuxnet: hab ich schon erledigt, kein Unterschied

 

[plang.pl]

@Tuxnet Das behebt das Problem nicht. Eine DS erhält in den seltensten Fällen einen neueren Kernel, sondern bleibt auf dem, mit dem sie ausgeliefert wurde.
Wegen der Sicherheit würde ich mir da, wenn die DS nicht im Internet hängt, keine Sorgen machen. Mir ging es da auf lange Sicht eher um die Vermeidung von Problemen. In Zukunft und auch jetzt schon verliert man teils einige Features von modernen Containern oder kann diese erst gar nicht nutzen, wenn der Kernel zu alt ist. Das Sicherheitsproblem beginnt ja nicht beim Nutzen von unbound, sondern bereits beim Asbach-uralten Kernel an sich