ClearFoundation Tracker - ClearCenter
Backups fail to run. No failure indication appears in the webconfig. Logs contain entries similar to:
/var/log/suva:Oct 1 00:00:02 satir rbs-schedule[20003]: Nothing to do at this time: 10 < 0 or 10 > 1
/var/log/suva:Oct 2 00:00:02 satir rbs-schedule[24291]: Nothing to do at this time: 10 < 0 or 10 > 1
/var/log/suva:Oct 3 00:00:01 satir rbs-schedule[25164]: Nothing to do at this time: 9 < 0 or 9 > 1
Cause:
This occurs due to a timezone handling bug in /var/webconfig/scripts/script.inc.php. This code uses a 'date %Z' command to obtain a short (typically 3 letter) abbreviation for the system timezone, which it then uses to set the timezone for the PHP environment. Unfortunately such abbreviations are not unique (eg. both Australia and the U.S.A. use EST, CDT and others), so the timezone of the PHP environment can be set incorrectly. This leads to /var/webconfig/scripts/rbs-schedule.php deciding it has been invoked at the wrong time, and exiting with the log message given above.
Patch:
I have attached a patch which resolves the immediate issue by using a 'date %Z%z' command to retrieve a UTC offset as well as a 3-letter abbreviation; taken together these do uniquely determine the system timezone. The main logic is in script.inc.php WebConfigScript::SetTimeZone. This patch also cleans up the error handling in that function (what's the point of second-guessing errors from date_default_timezone_set, it's actually counter-productive) and removes some confusing and redundant (probably hangover) code in rbs-scheduler.php.
WRT to the following; apologies if anyone thinks I'm stepping on toes or have no clue, I'm just putting in my two developer cents. No harm intended.
I think a little more work is required to properly fix timezone handling; I can see quite a few problems:
- It seems wrong for WebConfigScript::SetTimeZone to happily set UTC if the real system timezone can't be set.
- It seems wrong to automagically call SetTimeZone in the WebConfigScript constructor, and then eat up any CODE_INVALID_TIMEZONE exception. Doing that means the calling code can't set policy; the scheduler will never see this error.
- Why does the scheduler simply exit if it thinks it has been invoked at the wrong time? Instead of giving up, it should do it's best to perform a backup.
- Deducing the system timezone using /bin/date seems a little kludgy. Doesn't the webconfig know the local timezone? Could it be put in PHP.INI? Or, system setup could save the timezone somewhere. Eg. my gentoo system saves "Australia/Melbourne" in /etc/timezone; init scripts then use that to set up /etc/localtime.
There also seem to be some policy / error handling issues in the scheduler. For a backup, I think correct behaviour is something like "when in doubt, do a backup ; notify the user on any failure". As far as the end result is concerned, an error in the scheduler is no different to an error in the remote backup code (ie. RemoteBackupService) itself; if the backup fails, it fails. There are code paths in rbs-schedule where the backup can fail without (email or webconfig) notification (not least, the RemoteBackupService is constructed outside any try block), perhaps it needs a pair of eyes and a once over.
Ok, so that was maybe, like 42 cents, not two :)
fix_backup_timezone_handling.patch (1,973) 2011-10-23 23:02https://tracker.clearos.com/file_download.php?file_id=15&type=bug