bjm
29. Oktober 2023 um 17:28
1
Hallo.
qleg
29. Oktober 2023 um 17:30
2
Ich bestätige das gleiche Verhalten in meinen Szenen.
Haben Sie die Zeitzone in den Docker-Umgebungsvariablen richtig gesetzt?
-e TZ=Europe/Paris
bjm
29. Oktober 2023 um 17:42
4
Und wie findet man diese Variable?
Sie können den Container mit diesem Befehl inspizieren
docker inspect gladys | grep TZ
bjm
29. Oktober 2023 um 17:46
6
ich habe mich per SSH verbunden
Das bedeutet, dass der Gladys-Container keine Zeitzone hat.
In der Dokumentation sind alle Variablen aufgeführt, darunter auch die Zeitzone (die es ermöglicht, die Uhrzeit automatisch zu ändern) Installation avec Docker | Gladys Assistant
Falls Gladys vor langer Zeit installiert wurde, war das vielleicht noch nicht vorhanden
bjm
29. Oktober 2023 um 17:55
8
Das bedeutet also, dass die Variable nicht im Raspberry-Pi-Image vorhanden ist. Nur zur Sicherheit habe ich überprüft, dass die Zeitzone korrekt eingestellt ist auf
(GMT+01:00) Paris
Ach entschuldige, wenn es mit dem Gladys-Image für Raspberry Pi ist, ist das anders.
Die Zeitzone basiert auf /etc/timezone, die als Volume in den Container gemountet wird.
Kannst du bitte die folgenden Befehle ausführen?
cat /etc/timezone
docker inspect -f '{{ .Mounts }}' gladys
bjm
29. Oktober 2023 um 18:08
10
pi@gladys:~ $ cat /etc/timezone
Europe/Paris
pi@gladys:~ $ docker inspect -f '{{ .Mounts }}' gladys
[{bind /dev /dev true rprivate} {bind /etc/localtime /etc/localtime ro false rprivate} {bind /etc/timezone /etc/timezone ro false rprivate} {bind /run/udev /run/udev ro false rprivate} {bind /sys/class/gpio /sys/class/gpio true rprivate} {bind /var/lib/gladysassistant /var/lib/gladysassistant true rprivate} {bind /var/run/docker.sock /var/run/docker.sock true rprivate}]
pi@gladys:~ $
Alles ist OK
Ich denke, ein Neustart von Gladys wird das Problem lösen. Aber das Beste ist, bis morgen zu warten, @pierre-gilles kann sicherlich weitere Informationen anfordern oder eine dauerhafte Lösung geben.
bjm
29. Oktober 2023 um 18:17
12
Ich habe Gladys neu gestartet.
Hallo zusammen
Ja, das ist ein bekannter Bug von Gladys, wir hatten das Problem schon früher bei der Zeitumstellung.
Das Problem kommt von der Bibliothek, die wir für die Planung von Szenen verwenden ( node-schedule ), anscheinend wird die Zeitumstellung nicht richtig gehandhabt.
Ich habe einige Threads zu diesem Thema gesehen:
ouvert 01:57PM - 27 Apr 18 UTC
I have a job running every second.
Here in Belgium, the clock went from 2018-… 10-28T03:00+02:00 to 2018-10-28T02:00+01:00.
My scheduled job did not run for 1 hour after the change, and started running again at 2018-10-28T03:00+01:00.
Probably the decision on whether or not to trigger the job is comparing local timestamps?
ouvert 05:53PM - 31 Mar 16 UTC
fermé 06:29PM - 14 Nov 17 UTC
There have been repeated issues about crashes and infinite loops caused by chang… ing the date, especially due to daylight savings time changes. See #11, #131, #132, #214, #208. This issue is aimed to be a consolidation of those issues and a final solution. It would be good if we could avoid closing this until we absolutely sure that this is fixed for good.
This issue has caused downtime for us two years running now (when the clocks go forward at the end of March in the UK), with `0.1.13` and `0.1.16`, and I've only just worked out that node-schedule is the cause.
Most of the issues above point to the `while (true)` loop in `nextInvocationDate()`, which can get stuck when `Date` either doesn't increment or jumps back unexpectedly. For example, it will increment one minute at a time... `00:58:00`, `00:59:00`... but then jumps back to `00:00:00` because `01:00:00` does not exist on the night of daylight savings time.
This has been reported for `0.1.8`, `0.1.13`, `0.1.16`. Apparently it's fixed every time, only to find a new report against the next version that it's still similarly broken. One comment said there was a complete overhaul of this to fix it once and for all in `1.0.0`, but I've just upgraded to `1.1.0` and it's **_STILL**_ broken! Daylight savings time... the endless source of bugs :(
To reproduce:
```
var sinon = require('sinon');
var clock = sinon.useFakeTimers(+new Date(2016, 2, 26, 23, 59, 55), 'Date', 'setTimeout');
console.log('NEW DATE', new Date());
var schedule = require('node-schedule');
setInterval(function () {
clock.tick(1000);
console.log('NEW DATE', new Date());
}, 1000);
schedule.scheduleJob({ minute: 0 }, function () {
console.log('MARK ' + new Date());
});
```
Run the above with version `0.1.16` or `1.1.0` and it will go into an infinite loop when reaching `01:00:00`. Depending on the version it will may be running the job repeatedly or just constantly trying to work out the next job time.
It seems there are two variations of this bug:
1. `nextInvocationDate` going into an infinite loop trying to work out the date of the next instance
2. Running an event at `00:00:00`, working out the next event is at `00:00:00` (because `01:00:00` got changed back to `00:00:00`), running the event again, working out the next event is at `00:00:00` again, etc.
3. Any others?
What can be done to finally fix this for good? How might it be rewritten if we start with the assumption that `Date` is malicious and will **actively try** to cause an infinite loop if it can?
Thanks.
ouvert 04:26AM - 04 Dec 13 UTC
fermé 01:44AM - 04 Dec 15 UTC
feature
Can this module has a way to set the timezone for job schedules?
It seemed that … this repo hasn't been update for a long time.
Mal sehen, ob wir einen Fix über diese Bibliothek finden, oder ob wir eine andere Bibliothek in Betracht ziehen müssen
Ich habe ein Github-Issue erstellt:
ouvert 08:44AM - 30 Oct 23 UTC
fermé 09:05AM - 08 Jun 25 UTC
stale
blocked
Gladys keep the old hour in scene after a daylight saving time change.
Restarti… ng Gladys fixes the issue.
The issue comes from the `node-schedule` NPM library.
https://github.com/node-schedule/node-schedule/issues/435
https://github.com/node-schedule/node-schedule/issues/267
https://github.com/node-schedule/node-schedule/issues/34
We can either find a new library or try to fix this one
https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428
