Comment 9 for bug 1392292

I have dug into this more, and found that when clock setting changes to "Automatically" the script /etc/network/if-up.d/ntpdate is triggered and in the end the command

/usr/sbin/ntpdate -s ntp.ubuntu.com

is executed. When this happens, I have seen TWO very different kinds of errors, the same in *mako, arale, and frieza*. These are:

*** ONE

ntpdate fails to resolve DNS names or cannot connect to servers. I see traces in syslog like:

ntpdate[1571]: name server cannot be used: Temporary failure in name resolution (-3)
ntpdate[2599]: no server suitable for synchronization found

However, when I execute ntpdate from the command line ( /usr/sbin/ntpdate -d -s ntp.ubuntu.com ) things look good, and I can browse too. This error usually goes away after switching on/off flight mode (as in the bug description) or rebooting. It seems an error in networking configuration.

*** TWO

When ntpdate can connect to the servers, it is not always able to set the right date/time, and it depends on how deviated we are from real time:

- If we have set manually the date/time to the past, it works fine (at least for values of less that a decade)
- If we have set manually the date/time to the future, ntpdate is able to correct it if we are just a few hours in the future, but it fails to change the time if the deviation is one day or more. The error that appears in syslog is:

ntpdate[4809]: Can't adjust the time of day: Invalid argument

which seems to happen because ntptime is calling adjtime() glibc function with values that are much bigger than the theoretically supported for this function ( see http://man7.org/linux/man-pages/man3/adjtime.3.html ).

The question for this one is whether this is a ntpdate bug (maybe just for arm?) or if ntpdate should not really be used for this job.

Finally, for testing this I have used UTC+0 to avoid time zone to interfere.