With baselayout-1.13.0_alpha7-r1: If CLOCK="local" in /etc/conf.d/clock, AND timezone is UTC-x (not plus), AND certain of the initscripts have recently been changed (within the -x time), there will be warnings about future changetimes while calculating service dependencies, since that is done before the clock service is started and therefore before the offset to local time has been accounted for. With UTC-x local time, these files will appear to have been modified in the future, since the system time is assumed to be UTC at that point. I'm not sure how difficult it is to get clock offset info that early in the process, but if it's complicated, what about punting it with another simple variable that can be set to the appropriate offset value, then using that in the calculations? That would avoid warnings over nothing, if set correctly, without making things worse if not.
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.
