| Summary: | hwclock not being called on shutdown/reboot | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | RPM Packages | Assignee: | Base system maintainers <basesystem> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA6TOO | ||
| Source RPM: | initscripts-9.55-13.mga5.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2015-11-05 15:38:06 CET
Calling a command on shutdown does not sound like the solution, but rather a hack. I mean if power is lost, it would still break too right? I wouldn't approach this problem from a "here is the solution" but rather to think about it fully and then take appropriate action. Can you tell me what the output from: "timedatectl" is on these machines? I'm especially interested in the "RTC in local TZ" result. I'm presuming this says "yes" on your setup. Can you confirm this before I think about this more? Obviously, having the hwclock in localtime is prone to problems (the man page of hwclock says this and we don't recommend it in our installer etc etc.). If it's kept in UTC, then the kernel should sync things every 11 minutes anyway... I guess if you have "no" in the output for "RTC in local TZ" that either the server was rebooted before the sync happened or, for some reason, the sync never happened and we need to investigate that more. [Regarding sssd, you could tell sssd.service to be After=time-sync.target] (In reply to Colin Guthrie from comment #1) > Calling a command on shutdown does not sound like the solution, but rather a > hack. I mean if power is lost, it would still break too right? I wouldn't > approach this problem from a "here is the solution" but rather to think > about it fully and then take appropriate action. Well, the time still should be synced on shutdown, but yes if you lose power you'll still have a problem. > Can you tell me what the output from: "timedatectl" is on these machines? > I'm especially interested in the "RTC in local TZ" result. Local time: Thu 2015-11-05 12:23:04 EST Universal time: Thu 2015-11-05 17:23:04 UTC RTC time: Thu 2015-11-05 12:23:04 Time zone: America/New_York (EST, -0500) NTP enabled: yes NTP synchronized: yes RTC in local TZ: yes DST active: no Last DST change: DST ended at Sun 2015-11-01 01:59:59 EDT Sun 2015-11-01 01:00:00 EST Next DST change: DST begins (the clock jumps one hour forward) at Sun 2016-03-13 01:59:59 EST Sun 2016-03-13 03:00:00 EDT Warning: The system is configured to read the RTC time in the local time zone. This mode can not be fully supported. It will create various problems with time zone changes and daylight saving time adjustments. The RTC time is never updated, it relies on external facilities to maintain it. If at all possible, use RTC in UTC by calling 'timedatectl set-local-rtc 0'. > I'm presuming this says "yes" on your setup. Indeed. > Can you confirm this before I think about this more? Obviously, having the > hwclock in localtime is prone to problems (the man page of hwclock says this > and we don't recommend it in our installer etc etc.). If it's kept in UTC, > then the kernel should sync things every 11 minutes anyway... I guess if you > have "no" in the output for "RTC in local TZ" that either the server was > rebooted before the sync happened or, for some reason, the sync never > happened and we need to investigate that more. I know it's sucky having the hwclock in local time. It's only like this because it was initially installed as a dual-boot with Windows 7 (which isn't being used anymore, so I suppose I could just change it now). Regardless, we're supposed to be ordering new machines soon and those will be Linux-only and have their hardware clocks in UTC. Still, hardware clocks can drift, so even if it's only off by 6 minutes, kerberos still will balk at it. > [Regarding sssd, you could tell sssd.service to be After=time-sync.target] Thanks, I'll do that. @ David Walser, Can this report be closed, or should it be set to Cauldron + MGA6TOO and reassigned to the basesystem maintainers? CC:
(none) =>
marja11 Probably the latter, as I don't believe it has been addressed. (In reply to Marja Van Waes from comment #3) > @ David Walser, > > Can this report be closed, or should it be set to Cauldron + MGA6TOO and > reassigned to the basesystem maintainers? (In reply to David Walser from comment #4) > Probably the latter, as I don't believe it has been addressed. ok :-) Assignee:
mageia =>
basesystem |