Zitat von Markus <pet2...@epbfi.com>:
On 11/4/2014 03:36, Marco van Wieringen wrote:On 11/ 4/14 05:55 AM, Markus wrote:I'm still new to Bareos and I do not know where to file a bug report - and if this problem will be considered a bug. The Bareos version I am using is 13.2.At best its a feature request. Its known that the scheduler is not daylight saving compliant that was already true in Bacula and still is in Bareos as we didn't change anything major in the scheduler.Bareos's scheduler is not "daylight saving" proof. Last Sunday daylight saving time ended here in the USA. At 02:00 the clock went back to 01:00. My weekly backups are scheduled for Sundays at 01:00. They started as expected and an hour later (when Linux turned the clock back) they were added to the job queue again.Correct and here you already have one of the many problems to implement this in any way. In Europe we went to winter time a week earlier and it happens at 3:00 am and then goes back to 2:00 am so you have the time between 2:00 and 3:00 twice. Seems the Americas choose something different and for sure there are many more (think there are even timezones that stopped using daylight saving time at all etc.)So obviously you should not schedule anything between 01:00 and 02:00 on Sundays because it will be rescheduled when daylight saving ends and the clock is turned back. I therefore also have to assume that it is not wise to schedule anything between 02:00 and 03:00 on Sundays because it might get skipped when daylight saving goes into effect and the clock is turned forward.Correct seems there Europe and the Americas are aligned as that also happens here but probably at a different date.I have set my weekly backup jobs to 00:55 on Sundays now which will avoid these problems. Anyway, just wanted to let everybody know to be careful with the scheduling. Bareos is obviously not as smart as anacron.Its probably as smart as the original UNIX cron. To be smarter you have to be fully aligned with the whole timezone data which means a lot of code to handle it and hope that everything gets captured right in the timezone files. As we are a open source project feel free to enhance the scheduler to be timezone aware but keep in mind we run on quite a number of platforms so it will be quite some work to get it implemented in a generic way that works on most. Maybe anacron can be of help don't have the urge to investigate that myself but if people are feel free.Well, I understand that it's not a high priority problem. And there's a workaround - just don't schedule anything during your local time shifts. Anyway, thinking about the problem itself ... wouldn't all the problems in the scheduler be solved if the scheduler would just run in UTC internally? All it would need would be a conversion from local time to UTC, which should be no problem on any system with a working time zone implementation. Once all scheduled times are in UTC, there is no more "back and forth", regardless of local timezones and all their oddities. Markus
As long as you expect your starttimes to be at local times the problem persists, because the same point in (local) time could happen twice a day. To only workaround could be to set some status created from day and starttime to check if the same trigger has already fired at the same day, or to check for daylight saving switch.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
