Arch Linux

pantaril

Member

Registered: 2009-06-03

Posts: 7

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

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?

hcjl

Member

From: berlin

Registered: 2007-06-29

Posts: 330

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

i have got the same problem on some of my machines. obviously cron.hourly remained, if there were some of my manually written scripts in it. on the machines where online the adjtime time scripts was in it, it got deleted.

tomegun

Developer

From: France

Registered: 2010-05-28

Posts: 661

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

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.

The culprit is initscripts (i.e. me). We no longer use cron from initscripts, so if you don't have any other files in cron.hourly the directory gets deleted. This is actually a pacman bug, as the empty dir is owned by other packages as well. The bug is fixed in pacman git so should be sorted in pacman 4.0.

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.

If you use ntp, then that will take care of syncing your clock. If you don't (and don't use dual-boot), then you should enabled the hwclock daemon in your daemons array which will sync your clock on shutdown. There is no point in syncing more often. The only problem is if your computer crashes, but then the sync will be sorted out on next reboot and nothing will be lost.

Cheers,

Tom

tomegun

Developer

From: France

Registered: 2010-05-28

Posts: 661

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

This is the pacman bug: <https://bugs.archlinux.org/task/25141>.

pantaril

Member

Registered: 2009-06-03

Posts: 7

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

Thanks for the explanation.

I'm using openntpd as my time server and i'm unable to find any info if it syncs system time to hw clock or not.

I'm running my servers 24/7 with only scheduled restarts once in a long time so syncing clocks in shutdown script is not enough for me.

I had some problems in the past with my hw clock being off by a large ammount and then, when my server power-cycled due to power failure, it didn't boot up properly, because the fsck hanged with the message "FSCK: Superblock last write time is in the future" (it was a problem, becaouse the server is remotely managed with no human operator present on site).

So the adjtime script is not completely useless and i reenabled it on my systems.

tomegun

Developer

From: France

Registered: 2010-05-28

Posts: 661

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

I'm using openntpd as my time server and i'm unable to find any info if it syncs system time to hw clock or not.

I believe openntpd does not do this correctly. It is not maintained afaic, so I gave up on it and moved to ntpd. Even if openntpd does not set the rtc from systemtime, I think it is not a good idea to use it together with the hwclock daemon, as that depends on being the one in charge of the time.

I'm running my servers 24/7 with only scheduled restarts once in a long time so syncing clocks in shutdown script is not enough for me.

The only time you will read the rtc is on boot, so the only sync that matters is the last one (on shutdown).

I had some problems in the past with my hw clock being off by a large ammount and then, when my server power-cycled due to power failure, it didn't boot up properly, because the fsck hanged with the message "FSCK: Superblock last write time is in the future" (it was a problem, becaouse the server is remotely managed with no human operator present on site).

So the adjtime script is not completely useless and i reenabled it on my systems.

In this scenarios I would not recommend using the hourly adjustment, as that will estimate the correct time (hwclock --adjust), while you already know the correct time due to using ntp. I'd suggest doing one of these things:

0) Install a different ntp daemon that works correctly with 11-minute-mode (see man hwclock for how this is supposed to work).

1) Use "hwclock --systohc" to set the rtc to systemtime (which is what you care about in case of fsck, and which you know is correct due to ntpd). Please make sure that your ntp does _not_ set the time itself though, or you will confuse hwclock (and weird things might happen to your time). As mentioned before, hwclock --adjust probably will not work well when ntpd is running.

2) Enable accept_time_fudge in e2fsck.conf.

3) Configure your UPS to alert your server to the fact that power is gone so that it will shut down correctly (this you should probably do anyway).

Wittfella

Member

From: Australia

Registered: 2008-05-27

Posts: 462

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

The only time you will read the rtc is on boot, so the only sync that matters is the last one (on shutdown).

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.

Cheers

tomegun

Developer

From: France

Registered: 2010-05-28

Posts: 661

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

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.

Wittfella

Member

From: Australia

Registered: 2008-05-27

Posts: 462

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

Cheers, thanks for info!

So you seem to being saying that if I don't use any ntpd internet sync arrangement or set the time manually myself (which sounds like you shouldn't be doing) then my system time will basically be permanently wrong (to some degree, maybe small, hopefully my HC is not that shithouse!)

tomegun

Developer

From: France

Registered: 2010-05-28

Posts: 661

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

So you seem to being saying that if I don't use any ntpd internet sync arrangement or set the time manually myself (which sounds like you shouldn't be doing) then my system time will basically be permanently wrong (to some degree, maybe small, hopefully my HC is not that shithouse!)

Correct. However, by a very small amount. If you don't use ntp the biggest problem by far is going to be the inaccuracy introduced when you originally set the time.