Beiträge von dlueth

@derelvis Achtung, Image ungleich Container. Aus einem einzigen Image können beliebig viele Container gestartet werden. Entweder direkt via docker run oder, wie in dem Fall meines Scripts, via docker create. Bei run wird der container halt gleich gestartet, bei create nicht.

Ich bin mir nicht sicher, würde aber vermuten dass du auf deiner Synology das init-script nicht brauchst sondern direkt in der Oberfläche alles einstellen musst.

Im Prinzip ist aber, wie du ja nun weißt, in jedem Container das gleiche Image drin. Tendenziell kann also jeder aus dem Image erstellte Container alles, was auch die anderen können.

Mein Container unterscheidet z.b. anhand des Mode Parameters ob er für sich betrachtet einfach nur idle läuft (Admin), er direkt easyepg startet (Run) oder crond (Cron), Der dann wiederum hinten herum easyepg zu den gewünschten Zeiten startet.

Hintergrund dafür ist, dass docker nach dem Single responsibility Prinzip arbeitet. Der "Hauptprozess" ist das einzige was docker kennen kann und überwacht. Kackt dieser Prozess ab, soll docker das merken und den Container ggf neu starten. So Dinge wie ein Webserver, Datenbank und php in einem Container sind daher auch streng genommen im Ansatz falsch. War ist der Hauptprozess? Was passiert wenn einer der anderen Prozesse nicht mehr läuft? Wie soll docker das mitbekommen?

@Publish3r schreibst Du direkt auf den Socket von tvheadend? Dann mach das einfach 2 Mal mit 5 Minuten sleep dazwischen.

@joto62 OK, danke! Ich schau Mal ob ich das irgendwie reproduzieren kann...

Zitat von joto62

Hmmm... funzt immer noch nicht.
So sieht es in der .env aus:

Code

export USER_ID="1099"
export GROUP_ID="1099"
export MODE="cron"
export TIMEZONE="Europe/Berlin"
export FREQUENCY="55 16 * * *"
export UPDATE="yes"
export REPO="sunsettrack4"
export BRANCH="master"
export PACKAGES=""

Ich wollte das um 16:55 heute/jetzt ein Epg erstellt wird.
Es wurde kein cronjob aufgerufen.
Scheint nicht zu funktionieren... leider , dlueth.

edit: gerade nochmal eine ganz neue .env angelegt und cronjob auf 17:20 Uhr....es wurde kein cronjob gestartet , leider.

m.f.g.joto

nur zur Sicherheit die Rückfrage: du hast den Container neu gestartet nach Änderung der .env?

@joto62 ja, sollte

@joto62 Jain, Du machst nichts falsch Du hast nur einen Fall erwischt der sich schlecht abbilden lässt, ich muss etwas ausholen:

Grundsätzlich ist es so, dass man docker via "docker run" auch eine env-Datei mitgeben kann anstelle der einzelnen Environment-Variablen. Das kann aber die Syno nicht, die kann nur einzelne Variablen. Ergo kommt der vorhandene Mechanismus nicht in Frage.

Was im Moment geschieht ist, dass der entrypoint des Containers (ein Shell-Script, das als Root gestartet wird) prüft ob eine .env-Datei im easyepg-Ordner liegt und nicht leer ist. Ist dem so, wird via "source /easyepg/.env" diese Datei eingelesen und angewandt. Das ist dann aber nur für den Context in dem der entrypoint gerade läuft.

Loggst Du Dich via "docker exec" in die Kiste ein wird der entrypoint nicht durchlaufen, Du hast also dementsprechend das env wie es von der Syno über die Variablen übergeben wird. Das ist aber nicht das, was der entrypoint verwendet.

Um mitzubekommen was wirklich der entrypoint hat musst Du nach einem "docker exec" entweder den entrypoint einmal von Hand aufrufen oder direkt "source /easyepg/.env" ausführen. Erst dann siehst Du was wirklich verwendet wird.

Ist doof, ich weiß, aber es scheint keine andere Möglichkeit zu geben, da alle anderen mir bekannten Wege für Linux-User ein env zu setzen ins leere laufen, da diese nur beim "echten" Login (was "docker exec" nicht macht, und auch su nur dann, wenn Du -l explizit angibst) durchlaufen werden. Was noch hinzukommt ist, dass der User mit dem easyepg letztlich ausgeführt wird selber gar keine Login-Berechtigung hat, ergo also auch ein "su -l" nicht funktioniert.

Ich hoffe das war halbwegs verständlich

Seit ein paar Tagen sind die neu gebauten Images von mir jetzt nicht mehr auf Basis von Debian Stretch-Slim, sondern Buster-Slim. Laufen sollte alles völlig ohne Probleme, ich schaue aber noch ob ich das Image nicht doch noch wieder etwas kleiner bekomme - Buster scheint sich da etwas anders als Stretch zu verhalten oder die Packages sind einfach größer.

@joto62 und evtl. noch andere:
Die Version die gerade gebaut wird unterstützt jetzt eine ".env" Datei neben der normalen Übergabe der Environment-Variablen über Command-Line respektive NAS-GUI. Wer das braucht oder mal testen möchte kann in dem reingereichten Ordner für easyepg einfach eine leere Datei mit dem Namen ".env" anlegen (oder sie auch mit -v bzw. als Volume von woanders aus reinmounten beim "docker run").

Diese Datei wird, so sie vorhanden und leer ist, einmalig(!) mit den dem Container beim "docker run" übergebenen env-Variablen befüllt. Ist sie vorhanden und nicht leer wird sie beim Starten des Containers automatisch eingelesen und verarbeitet und überschreibt(!) dann ggf. via "docker run" übergebene Variablen (was Dein Problem beheben sollte auf der Syno @joto62). Hat man die Datei also einmal erstellt und befüllt, kann man sich im Anschluss die Übergabe via GUI sparen und nur noch mit dem File den Container konfigurieren.

Probier Mal nicht den folder reinzumappen, sondern direkt eine Datei mit dem Namen deiner kombinierten XML. Wenn ich es richtig weiß, dann geht das.

Und noch eine Rückfrage @joto62:

Ist FREQUENCY zufällig der erste/letzte Eintrag der Liste an Parametern im Web-IF der Syno für diesen Container? Würde es evtl. Sinn machen den Parameter für Dich mal testweise umzubenennen?

@joto62 Ergänzende Rückfrage: Kannst Du meine Frage unter 2. oben nochmal beantworten bitte?

Also: Übergibt die Syno bei jedem weiteren Start gar nichts (was dann zum default von 2:00 Uhr nachts führt) oder kompletten Unsinn?

Jo, ist gut, gib mal bescheid auf jeden Fall. Normalerweise würde ich das wohl auch so sehen und nur ungern ne "Sonderlösung" einbauen, aber die Idee ist eigentlich relativ simpel:

Im Dockerfile definierte Volumes werden seitens Docker immer persistiert, wenn sie nicht sowieso von außen übergeben werden. Genau in einem solchen Volume könnte man also initial die Frequency oder vielleicht auch das komplette Cron-File ablegen. Beim starten würde dann geprüft werden, ob in dem Volume bereits Werte (bzw. eine entsprechende Datei) liegen und wenn ja, würden diese die übergebenen "Overrulen". Man bräuchte dann lediglich einen weiteren Parameter für den Container mit dem man diesen "Modus" aktivieren kann, da er halt nicht für alle nötig ist und ggf. zu Problemen führen könnte, wenn jemand nachträglich die Frequency anpassen will (und es technisch möglich ist, anders als bei Syno scheinbar).

@joto62 Nur nochmal zum Abklopfen, ob meine Idee einer Lösung funktionieren würde:

1. Bei frischer Installation auf der Syno übergibt er beim ersten start die FREQUENCY korrekt?
2. Bei jedem weiteren Start übergibt die Syno Murks (oder gar nichts, so dass der Default von 2:00 Uhr nachts greift?)

Gibt es ne Chance, dass der behoben wird seitens Synology? Wenn nicht, hätte ich ne Idee für ne Lösung...

Eigentlich sogar "${variable}", das wird es sein, so oder so

Sieht aus wie die Verzeichnisse der root-ebene...

@joto62 kannst du Mal bitte innerhalb des Containers ein cat /etc/easyepg.cron machen und Posten was da heraus kommt?

Gehe ich Recht in der Annahme, dass das was du gesetzt hattest im Fall des Outputs oben 2 Mal den * beinhaltete?

Klingt eher nach nem Bug im web-if deiner syno imho...

@Kampfader ich pushe gleich nochmal eine neue Version des init-scripts zu GitHub. Dann sollten ggf laufende Versionen meines Containers zuverlässig gestoppt, entfernt und auch zugehörige Images entfernt werden sowie ein neues gepulled.

edit: ist gepushed...

Also an den Parametern für den Container hat sich schon lange nichts geändert, auch nicht an den defaults. Es ist nur einer hinzugekommen, der ist aber eigentlich nur für Tests von @DeBaschdi gedacht und sonst für niemanden interessant und tut nichts, wenn man ihn nicht ausfüllt.

Manchmal gibt's so kack-tage, heute wird bestimmt besser

@BJ1 Die Defaults für die einzelnen Werte stehen auf GitHub, Du musst natürlich nur die Abweichungen angeben

@BJ1 Welcher Grabber wäre auch noch interessant... Und hast Du zufällig vom docker.hub einen der test-tags "latest-alpine" erwischt?