Clock doesn't update when switching time from manual to automatic

[Jean-Baptiste Lallement]

TEST CASE:
1. Go to system-settings/datetime and switch the phone to manual date/time update and set a date/time different from your current time
2. Switch back to automatic
3. Wait until clock updates to the right date/time

EXPECTED RESULT
The clock of the device is updated when settings is switched to automatic

ACTUAL RESULT
The clock of the device doesn't update unless flight mode it toggle on/off

ProblemType: Bug
DistroRelease: Ubuntu RTM 14.09
Package: ubuntu-system-settings 0.3+14.10.20141104~rtm-0ubuntu1
Uname: Linux 3.4.67 armv7l
ApportVersion: 2.14.7-0ubuntu8
Architecture: armhf
Date: Thu Nov 13 11:51:22 2014
InstallationDate: Installed on 2014-11-12 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20141112-181954)
SourcePackage: ubuntu-system-settings
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastien Bacher (seb128)]

Thanks but I can't confirm that, after selecting "automatic" the time at the bottom of the settings panel catch up less than 10 seconds later. In any case not a settings bug, we call the systemd's helper to change to ntp on, if that doesn't work it's an issue with ntp/systemd

[Sebastien Bacher (seb128)]

not that you mention flight mode, automatic is ntp and requires data to be enabled

[Jean-Baptiste Lallement (jibel)]

I mentioned flight mode because it's a way to resync the clock but when I switch to automatic wifi and cellular data are both enabled.

[Jean-Baptiste Lallement (jibel)]

in my case when I select "automatic", the date at the bottom of system-settings doesn't change.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

This is all UI, not timedatectl. timedated does nothing which is related to this, as ubuntu touch uses ntpdate (which isn't really configurable, it always runs in the DHCP hook). Please also see bug 1390120 which is the inverse of this.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

I have run into this on arale: changing manually the date and then switching to automatic did not change back the date.

- I tried rebooting first, but that did not change the date either
- Then I tried set on, then off flight mode, that worked

Finally we are seeing this quite often in frieza, and there I did not get the date back even by using the flight mode trick, so I think that the priority of this should be risen.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

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.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Some testing on desktop shows that

1. ntpdate behaves in the same way as on Touch (second error in comment #9)

2. Time&Date settings do not use ntpdate, but systemd-timedated and systemd-timesyncd, which seem to work fine in all cases

[Jean-Baptiste Lallement (jibel)]

for reference I filed bug 1526264 for the case where ntpdate fails when the date is in the future.