bjm
October 29, 2023, 5:28pm
1
Hello.
qleg
October 29, 2023, 5:30pm
2
I confirm the same behavior in my scenes.
Do you have the timezone correctly set in the Docker environment variables?
-e TZ=Europe/Paris
bjm
October 29, 2023, 5:42pm
4
and how do we find this variable?
You can inspect the container with this command
docker inspect gladys | grep TZ
bjm
October 29, 2023, 5:46pm
6
I connected via SSH
That means the Gladys container has no timezone.
In the documentation, there are all the variables including the timezone (which allows the clock to change automatically) Installation avec Docker | Gladys Assistant
If Gladys was installed a long time ago, maybe it wasn’t present yet
bjm
October 29, 2023, 5:55pm
8
So this means that the variable is not present in the image for Raspberry Pi
(GMT+01:00) Paris
Ah sorry, if it’s with the Gladys image for Raspberry Pi, it’s different.
The timezone is based on /etc/timezone which is mounted as a volume in the container.
Can you run the following commands?
cat /etc/timezone
docker inspect -f '{{ .Mounts }}' gladys
bjm
October 29, 2023, 6:08pm
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:~ $
Everything is OK
I think restarting Gladys will resolve the problem. But it’s best to wait until tomorrow; @pierre-gilles will surely be able to ask for more information or provide a lasting solution.
Hello everyone
Yes, it’s a known Gladys bug — we’ve already had the issue during clock changes in the past.
The problem comes from the library we use to schedule scenes (node-schedule ); apparently they don’t handle clock changes well.
I saw a few threads discussing the issue:
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.
We need to see whether we can find a fix via this library, or whether we should consider another library.
I created a GitHub issue:
ouvert 08:44AM - 30 Oct 23 UTC
fermé 09:05AM - 08 Jun 25 UTC
bug
stale
waiting-for-external-fixes
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
