/etc/cron.hourly disappeared after tonight's update.

Question

Hi,
after tonight's system update, the /etc/cron.hourly directory disappeared without any warning and now i get error message from cron "Usage: /usr/sbin/run-cron crondir" every hour, because the line "01 * * * *  /usr/sbin/run-cron /etc/cron.hourly" remained in root's crontab.
I can confirm this issue on both of my archlinux machines, they are both 64bit versions of arch.
The list of updatet packages:
boost-libs-1.47.0-1  boost-1.47.0-1  encfs-1.7.4-5
freetype2-2.4.6-1  initscripts-2011.07.3-1  libass-0.9.12-2
perl-list-moreutils-0.32-1
In my backups, i can see that the /etc/cron.hourly directory contained the "adjtime" script, which synced the system clock to the hw clock, which i find usefull.
Is this change intentional or shall i file bug report? If the change is intentional, where were the adjtime script moved?

Answer 1

Wittfella wrote:
Hey tomegun, quick question - why is the --adjust not made at startup.  It looks like the rc.sysinit specifically uses --noadjfile and I cannot see a 'hwclock --adjust' anywhere in the startup sequence.
Say for instance, lets exaggerrate and my HARDWARECLOCK is useless and loses 1 hour/day.  At shutdown it is synced and adjusted, so that it is correct, no problem.  If my computer is off for 5 days, theoretically when I boot the HC will be 5 hours behind.  Wouldn't you have to 'hwclock --adjust' prior to setting the system time.
Good question!
This is the situation:
The kernel sets the time unconditionally from the rtc before user space is started (so before we can invoke hwclock --adjust).
hwclock can not adjust the system time gradually like, say, ntpd does. It will make the time jump (possibly backwards!) to the desired value. This is a no-go, as system time must always be monotonic or very bad and unpredictable things might happen.
To make matters worse, the driftrate is stored on /var, which is only accessible late in the boot process (as /var might need to be mounted first).
The only thing we can safely do, is to correct the rtc clock without reading it back into system time. We therefore do this at shutdown, so next time we boot the only error in time will be what is accumulated between last shutdown and boot. In other words your example is correct, and the clock would be 5 hours late (that said, an rtc clock which drifts more than a certain amount is not following the spec so should be considered broken). The silver lining here is that the errors will not accumulate. That is, if you repeat the process (shut the computer off again, wait five days and turn it back on) the clock will still "only" be five hours off and not ten.
Clearly this situation is highly unsatisfactory. I have been looking into other solutions (the hwclock maintainers seem uninterested in improving it as they basically assume people don't use it any more), and it looks to me that the ntp client Chrony does exactly what we would want: In the case you have internet access it uses ntp to get a correct time, otherwise it uses rtc, and it always keeps the rtc's driftrate calculated so it can make sensible estimates. Furthermore, the time is set in a way that ensures that systemtime is monotonic (like any ntp server would do), and we don't get the problem we have now that ntpd and hwclock steps on each other's toes.
If anyone has any knowledge/experience of/with Chrony, I'd be interested to hear about it.