ailispaw/boot2docker-xhyve

Installing cron in boot2docker-xhyve to fix clock drift

Closed this issue · 15 comments

girvo commented

From what I can see, there is no cron installed in boot2docker-xhyve, is this correct?

One interesting bug is that the clock drifts while the host machine is asleep; this can cause things like AWS APIs to fail within Docker.

An easy fix is to run sudo ntpclient -s -h pool.ntp.org in the boot2docker VM. Ideally I'd like to put this in a crontab, however without cron in the VM, I am rather at a loss!

Any ideas?

boot2docker/boot2docker has /usr/sbin/crond and /usr/bin/crontab.

docker@boot2docker~$ cat /var/spool/cron/crontabs/root
# restart ntpd to combat laptop sleep + VM pause
0 * * * * killall ntpd > /dev/null 2>&1; /etc/rc.d/ntpd

Or just $ sudo reboot would be fine.

girvo commented

Ah beautiful, I couldn't find the crontab for the life of me. Thanks!

Sent from my iPhone

On 2 Oct 2015, at 11:26 AM, A.I. notifications@github.com wrote:

boot2docker/boot2docker has /usr/sbin/crond and /usr/bin/crontab.


Reply to this email directly or view it on GitHub.

xez commented

xhyve should take care of the clock drift during host sleep eventually.

@xez That would be great.

girvo commented

@ailispaw It seems that it is incorrect even using NTP?

screenshot

That's after a fresh boot of the VM. Any ideas?

@girvo What is your TimeZone?
It is UTC always in the VM by default.

girvo commented

@ailispaw Brisbane/Australia (UTC +10).

The main issue that this causes is breaking the AWS S3 API, as it whinges about clock drift being too large :(

@girvo
What about the time after executing sudo /usr/local/bin/ntpclient -s -h pool.ntp.org?
Will it adjust the clock correctly?

Oh you have already mention it at the first comment. Sorry.

I think that you can replace ntpd with ntpclient in the crontab and set more frequently.

Or you can run the following command in the host after resume. I think this is the easiest way.

$ make ssh -- sudo /usr/local/bin/ntpclient -s -h pool.ntp.org

That's after a fresh boot of the VM. Any ideas?

I have no idea... I've never seen that before.

@girvo BTW,

Brisbane/Australia (UTC +10) Oct 9, 9:44am -> Oct. 8, 23:44pm UTC
is correct.