bjm
Octobre 29, 2023, 5:28
1
Bonjour.
qleg
Octobre 29, 2023, 5:30
2
Je confirme le meme comportement dans mes scènes
Est-ce que vous avez bien la timezone dans les variables d’environnement Docker ?
-e TZ=Europe/Paris
bjm
Octobre 29, 2023, 5:42
4
et on la trouve comment cette variable ?
Vous pouvez inspecter le container avec ce cette commande
docker inspect gladys | grep TZ
bjm
Octobre 29, 2023, 5:46
6
je me suis connecté en ssh
Ça veut dire que le container Gladys n’a pas de Timezone.
Dans la documentation, il y a toutes les variables dont la timezone (qui permet de changer d’heure automatiquement) Installation avec Docker | Gladys Assistant
Si Gladys a été installé il y a longtemps, peut-être que ce n’était pas encore présent
bjm
Octobre 29, 2023, 5:55
8
Cela veux donc dire que la variable n’est pas présente dans l’image pour raspberry-pi
(GMT+01:00) Paris
Ah pardon, si c’est avec l’image Gladys pour Raspberry Pi, c’est différent.
La timezone est basée sur /etc/timezone qui est monté en tant que volume dans le container.
Est-ce que tu peux lancer les commandes suivantes ?
cat /etc/timezone
docker inspect -f '{{ .Mounts }}' gladys
bjm
Octobre 29, 2023, 6: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:~ $
Tout est OK
Je pense qu’un redémarrage de gladys permettra de résoudre le problème. Mais le mieux est d’attendre demain, @pierre-gilles pourra sûrement demander plus d’informations ou donner une solution pérenne.
Salut à tous
Oui c’est un bug connu de Gladys, on a déjà eu le soucis aux changements d’heures dans le passé.
Le souci vient de la librairie qu’on utilise pour programmer les scènes ( node-schedule ), visiblement ils ne gèrent pas bien les changements d’heures.
J’ai vu quelques threads qui parle du sujet:
opened 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?
opened 05:53PM - 31 Mar 16 UTC
closed 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.
opened 04:26AM - 04 Dec 13 UTC
closed 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.
A voir si on peut trouver un correctif via cette librairie, où si il faut envisager une autre librairie
J’ai créé une issue Github:
opened 08:44AM - 30 Oct 23 UTC
bug
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
