Summary: | baselayout early boot UTC vs local clock issues | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Duncan <1i5t5.duncan> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Duncan
2006-12-07 07:53:16 UTC
this issue is represented in plenty of other bugs introducing a hack to offset times is not going to happen Plenty of other bugs, perhaps, but previously, the clock service was special-cased and ran before any svctime-check, thus eliminating this particular issue with svctime-checks before clock was started and the system clock adjusted for local/utc. With 0.13, it's not, at least not yet, tho that's one possible solution. There are two sub-issues. The first and most visible are all the warnings, repeated not once but multiple times (once per bad time per service scanned?), if localtime is UTC-X, the system is set for localtime, and services or their configs were recently updated. That's not critical as it's just a bunch of harmless warnings. The second and potentially more troublesome is the timechecks for dependency tree updating. If those are incorrect, with UTC-X localtime, it "corrects" them to the wrong time in pre-clock-service scans and triggers an unnecessary deptree update. With UTC+X localtime, if I'm not mistaken, it will ignore recent changes and NOT do the deptree update in pre-clock-service scans, and after they are reset, will probably trigger the complaints above (and an unnecessary deptree update) for post-clock-service scans. It's an extra update in both cases, with the possibility of missing vital deptree changes for pre-clock-service scans in UTC+X localtime areas. After looking at the bash code a couple days ago and thinking about it a bit, I realized another way around it would be to simply bypass the checks and hard-update the deptree pre-clock. I think we are triggering the hard-updates anyway on one side of clock service or the other depending on UTC+ or - at the moment, so no loss of time hard-updating it pre-clock, and hard-triggering the deptree-update would avoid both the unnecessary warnings and the chance of missing a vital change in the pre-clock scans on the UTC+X side of the world. Of course, this is still assuming there's no simple clock API method to grab the update. There likely is (I should look it up...). If the assumption is correct, however, the choices I see are either (1) hard-coding the pre-clock deptree-updates to run regardless (using that early bootlevel flag, forgot what it was ATM), or (2) returning to the previous solution: hardcoding clock to run before any time scans. (In reply to comment #2) > clock adjusted for local/utc. With 0.13, it's not, Ugh. Obviously that should be 1.13. This should be fixed in baselayout-1.13.0_alpha11. Re-open if you disagree. |