Zitat von Markus <pet2...@epbfi.com>:
On 11/4/2014 10:54, lst_ho...@kwsoft.de wrote: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. MarkusAs 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 AndreasAndreas, I think you are partially correct. Of course I expect my start times to be 'local time' - in the configuration files. The director reads the configuration files and converts all start times to UTC (or UNIX time for that matter). The configuration files contain local times and the scheduler runs UNIX time. "The same point in time" never happenes twice in UNIX time. The only scenario to cause trouble I could think of would be if the scheduler re-reads the configuration files periodically. If reading the configuration files happenes just once (at startup or restart), then there should never be a problem if everything inside the scheduler runs in UNIX time. But I have not looked at the source code yet, so I may be wrong.
Let me rephrase it: If you expect the scheduler to obey local times eg. always start at 02:00 in you local timezone you have the problem that this timestamp might not be unique or does not exist at all at the day of daylight saving. If you use UTC as timestamp you don't have the problem of not unique/existing, but you must adjust your scheduler timestamps on daylight saving otherwise the (local) starttime will move. So as said the only option for not unique is to include the day in calculation, for the not existing local time stamp on switch day it is even worse...
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
