Watchtower Problem

[Typ1er]

Ich bekomme Watchtower nicht mehr gescheit zum laufen, ich habe mit diesem Befehl den Container angelegt, Updates werden aber keine mehr ausgeführt.

Typ1er@DiskStation:/$ sudo su
Password: 
ash-4.3# docker run -d --name Watchtower -v /var/run/docker.sock:/var/run/docker.sock v2tec/watchtower --interval 3600 --cleanup

Fehlermeldung aus dem Log:

time="2020-03-06T23:56:52Z" level=info msg="Unable to update container /Pihole, err='Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)'. Proceeding to next." 
stderr
23:57:07

Wo ist der Fehler?

 

[Der Paul]

Könnte ein DNS Problem sein. Nutzt Du für den PiHole Container ein MACVLAN und hast den PiHole as einzigen DNS im DSM eingetragen? Falls ja: trag mal einen zweiten DNS im DSM ein (Routeradresse oder zB 1.1.1.1)

 

[Adama]

Was auch sein könnte: Schau mal auf Deiner Syno, wo die docker.sock liegt.

Bei meiner liegt die nämlich unter /run, also /run/docker.sock, nicht /var/run/docker.sock

 

[Typ1er]

Könnte ein DNS Problem sein. Nutzt Du für den PiHole Container ein MACVLAN und hast den PiHole as einzigen DNS im DSM eingetragen? Falls ja: trag mal einen zweiten DNS im DSM ein (Routeradresse oder zB 1.1.1.1)

In der Fritzbox steht für die Internetverbindung der Google DNS drin, und beim DHCP Server der vom PiHole (docker), Pihole läuft im Host Mode ohne MACVLAN

@Adama
die Verzeichnisse /run/ und /var/run/ sind identisch bei mir

Hier wäre schön zu wissen auf welche docker.sock man verlinken muss, auch gibt es ja noch die Anleitungen mit dem Symlink:
https://www.synology-forum.de/showt...cker-Container&p=732156&viewfull=1#post732156

 

[Der Paul]

In der Fritzbox steht für die Internetverbindung der Google DNS drin, und beim DHCP Server der vom PiHole (docker), Pihole läuft im Host Mode ohne MACVLAN

Und was passiert, wenn Du im DSM direkt nur den Google DNS einträgst?

Hier wäre schön zu wissen auf welche docker.sock man verlinken muss, auch gibt es ja noch die Anleitungen mit dem Symlink:
https://www.synology-forum.de/showt...cker-Container&p=732156&viewfull=1#post732156

Mit exakt dieser im Thread genannten Einstellung läuft der Container bei mir anstandslos.

 

[haydibe]

Tipps dazu:
- Der Container-Parameter "--apiversion 1.23" wird mit der 19.0x Version vom Docker-Paket nicht mehr benötigt.
- Das Image v2tec/watchtower wird nicht mehr gepflegt, die Weiterentwicklung findet im Image containrrr/watchtower statt.

Typischerweise wird bei Linux-Systemen /var/run/docker.sock verwendet.
Beide sind auf der DS identisch (kann, muss aber nicht so sein bei anderen Linux-Systemen), siehe Ausgabe von `stat`:

root@dsm:~# stat /var/run/docker.sock
  File: ‘/var/run/docker.sock’
  Size: 0               Blocks: 0          IO Block: 4096   socket
Device: fh/15d  Inode: 28521       Links: 1
Access: (0660/srw-rw----)  Uid: (    0/    root)   Gid: (65536/  docker)
Access: 2020-03-08 00:02:02.372481810 +0100
Modify: 2020-02-25 14:04:37.656001318 +0100
Change: 2020-02-25 14:04:37.656001318 +0100
 Birth: -
root@dsm:~# stat /run/docker.sock
  File: ‘/run/docker.sock’
  Size: 0               Blocks: 0          IO Block: 4096   socket
Device: fh/15d  Inode: 28521       Links: 1
Access: (0660/srw-rw----)  Uid: (    0/    root)   Gid: (65536/  docker)
Access: 2020-03-08 00:02:02.372481810 +0100
Modify: 2020-02-25 14:04:37.656001318 +0100
Change: 2020-02-25 14:04:37.656001318 +0100
 Birth: -

Beiden zeigen auf dasselbe Device und denselben Inode == identisch

 

[Typ1er]

Ich habe den Container noch mal umgestellt, auf containrrr/watchtower, im Wiki ist dazu ja eine Anleitung, der bin gefolgt.

 

[luddi]

Sehe ich ob der watchtower container sauber läuft?

Ich starte den Container wie folgt:

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --interval 30

Anschließend werfe ich einen Blick in die Docker GUI unter DSM. Dort sehe ich unter Protokoll nur einen einzigen Eintrag, nämlich dass der first update für start time + 30 sec. gesetzt ist. Also erwartete ich 30 sec. nach dem Start einen weiteren Eintrag im Protokoll. Sowohl im Protokoll als auch im Terminal Window ist kein update zu sehen.



Wie sieht das bei euch aus?

--luddi

 

[DKeppi]

Ich verwende für den Container ganz einen anderen Befehl für das regelmäßige Update bzw. der Suche danach und der klappt einwandfrei

[FONT=&quot]--schedule "30 1,13 * * *"[/FONT]

Hier nachzulesen -> https://containrrr.github.io/watchtower/arguments/#scheduling


Allerdings scheint glaub ich im Log nur was auf wenn er auch neues findet

 

[luddi]

Okay danke dir für den Hinweis dass nichts weiter im Log erscheint.

Klar du machst es eben mit einer "Cron expression". Beides möglich!

Dann warte ich gespannt ob er bei einem gefundenen Update etwas im Log hinterlässt.

Danke dir vielmals DKeppi.

--luddi

 

[luddi]

Ich verwende für den Container ganz einen anderen Befehl für das regelmäßige Update [...]

--schedule "30 1,13 * * *"

Folgendes ist mir bei deiner Cron expression aufgefallen. Üblicherweise sind es 5 Parameter, hier beim watchtower beim Argument --schedule werden aber 6 verwendet.

argument schedulung
Cron expression in 6 fields (rather than the traditional 5) which defines when and how often to check for new images. Either --interval or the schedule expression could be defined, but not both. An example: --schedule "0 0 4 * * *"

Nur als Hinweis, solltest du dich wundern warum dein Job mit deinen Parametern zur Sekunde 30, zur Minute 1,13 und das zu jeder Stunde an jedem Tag usw. laufen sollte. D.h er müsste bei dir aktuell somit 2x pro Stunde (immer zur Minute 1m:30sec. und 13m:30sec) prüfen anstatt wie vermutlich gplant alle 12 Stunden (Stunde 1 und Stunde 13) jeweils zur Minute 30.

--luddi

 

[luddi]

[...] Sowohl im Protokoll als auch im Terminal Window ist kein update zu sehen.

Allerdings scheint glaub ich im Log nur was auf wenn er auch neues findet

Ich habe noch einmal genauer ins manual hineingeschaut und zusätzlich das Argument --debug verwendet. Somit bekommt man auch zu jedem Ausführungszeitpunkt einer Überprüfung (je nach Zeitintervall bzw. Schedule) die Informationen im Log angezeigt.

--luddi

 

[DKeppi]

HAHA Geil, danke für den Hinweis - das hab ich selbst wohl überlesen!
Der Hinweis mit --debug ist auch gut, den baue ich gleich ein

 

[Adama]

Das Offensichtliche hab' ich auch überlesen...

Hab' --debug grad mal getestet. Gibt schön aus, welchen Container er grad beim Wickel hat und ob's ein Update gibt...

 

[luddi]

Hallo Zusammen,

noch ein kleines Update bezüglich "scheduling" bzw. die Ausführungszeit.

Verwendet man das Argument --interval so spielt die Uhrzeit keine Rolle.
Möchte man aber den Trigger über das Argument --sechedule planen, so wird per default die Zeitzone "UTC" verwendet.
Dies hat zur folge dass die angegebenen Zeitpunkte des Parameters Stunde (h) "s m h D M Y" abhängig von der Normalzeit bzw. Sommerzeit abweichen.
Bei der Normalzeit in Europa würde dies eine Stunde entsprechen, und bei der Sommerzeit sogar zwei Stunden bei denen die Triggerzeitpunkte jeweils nach hinten verschoben werden bzw. später kommen.

Für Europa(DE) gilt:
- Normalzeit: CET = UTC+1
- Sommerzeit: CEST = UTC+2

Wenn man dieses Delta nicht in der schedule Konfiguration einbeziehen möchte dann startet man den Container mit folgenden Angaben damit die korrekte Systemzeit verwendet wird.

Hier ein Beispiel für einen Start des Containers. Die zwei grün markierten Zeilen sind dabei notwendig für die Übernahme Systemzeit.

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/TZ:/etc/timezone:ro \
  containrrr/watchtower \
  --schedule "0 15 */3 * * *" \
  --cleanup \
  --debug

In diesem Bespiel (blau markiert) ist der Startzeitpunkt einer Überprüfung auf jede dritte Stunde zur Minute 15 und zur Sekunde 0 definiert.
D.h. 0:15 --> 3:15 --> 6:15 --> 9:15 --> usw.

Ohne Korrektur der Systemzeit würden sich per default folgende Zeitpunkte ergeben:
Normalzeit (CET): 1:15 --> 4:15 --> 7:15 --> 10:15 --> usw.
Sommerzeit (CEST): 2:15 --> 5:15 --> 8:15 --> 11:15 --> usw.

--luddi

 

[DKeppi]

Bei mir hat es gereicht die Umgebungsvariable TZ in der Docker Gui mit CET zu setzen!

INFO[0001] Starting Watchtower and scheduling first run: 2020-03-31 01:30:00 +0200 CEST

 

[luddi]

Bei mir hat es gereicht die Umgebungsvariable TZ in der Docker Gui mit CET zu setzen!

Wo kann man in der Docker GUI eine Umgebungsvariable setzen? Ich sehe da nichts...

--luddi

 

[DKeppi]

Container stoppen - bearbeiten - im Reiter "Umwelt"

 

[Adama]

Du musst in den docker-Befehl noch dieses mit hinzufügen:

-e TZ="Europe/Berlin"

Das wäre z.B. mein Befehl, um Watchtower anzulegen und zu starten:

docker run -d --name Watchtower --restart always -e TZ="Europe/Berlin" -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower -s "0 0 0/6 * * *" --debug --cleanup

 

[luddi]

Container stoppen - bearbeiten [...])

@DKeppi: Ah da ist er versteckt! Da wäre ich nie drauf gekommen den Container in der GUI zuerst zu stoppen und dann zu bearbeiten. Ich hatte bisher alles über die Konsole gestartet.

-e TZ="Europe/Berlin"

@Adama: Das ist auch ein schönes Argument.


Vielen Dank euch Beiden.

--luddi