On Monday, December 18, 2017 9:51:29 AM CET BWC Illmensee GmbH - Ralph Gauer wrote:
It only seems to be illogical, as on some systems systemd ignores the conflict between systemd-timesyncd and ntpd that is defined in the service file for ntpd, but on other systems it respects this conflict and runs only either systemd-timesyncd or ntpd. I couldn't find out, what causes the difference.
ntpd.service: ... [Unit] ... Conflicts=systemd-timesyncd.service ^ This is a bug IMNSHO
On these systems I need to use fake-hwclock, as systemd-timesyncd doesnt't even start if both "systemd-timesyncd.service" and "ntpd.service" are enabled. If, after boot systemd-timesyncd is started, ntpd is automatically stopped. If then ntpd is started, systemd-timesyncd is automatically stopped. This wouldn't be a problem, if on boot systemd-timesyncd would start, correct the time and then, when ntpd is starting, would be stopped.
This would break the regular update of the timestamp and the timestamp update on shutdown. It would not even update the timestamp *once*, as timesyncd would be stopped before ntpd has locked. Stefan
Am 18.12.2017 um 09:34 schrieb Stefan Brüns:
On Monday, December 18, 2017 8:58:31 AM CET BWC Illmensee GmbH - Ralph Gauer> wrote:
systemd-timesyncd conflicts with ntpd. So if a ntpd service is needed, fake-hwclock is the better choice for time correction on boot.
Sorry, this statement (without further clarification) seems illogical - first you reported it works, now it does not?
timesyncd without an NTP daemon (or some other external time source, like GPS) can not work, as it only starts saving the timestamp after it has synchronized to this clock source.
Stefan
Am 11.12.2017 um 15:58 schrieb BWC Illmensee GmbH - Ralph Gauer:
Just rebooted a Rpi2:
First step in dmesg and journal (not from systemd-timesyncd): [ 3.411859] systemd[1]: System time before build time,
advancing clock.
Nov 29 11:11:43 Snorre systemd[1]: System time before build time,
advancing clock.
then later in journal: Nov 29 11:11:52 Snorre systemd-timesyncd[237]: System clock time
unset or jumped backwards, restoring from recorded timestamp: Mon 2017-12-11 15:48:26 CET
and then, when network comes up: Dec 11 15:49:02 Snorre start-ntpd[1053]: Starting network time
protocol daemon (NTPD)
Dec 11 15:49:45 Snorre systemd-timesyncd[237]: Synchronized to
time server 192.168.175.253:123 (raspi.gauernet.de).
An earlier version (just a few days ago) of the systemd-timesyncd had a little problem, because it stopped ntpd. Starting systemd-timesyncd stopped ntpd, starting ntpd stopped systemd-timesyncd. The current version doesn't have this problem, both services run simultaneously.
Ralph Gauer
Am 11.12.2017 um 14:20 schrieb Freek de Kruijf:
Op maandag 11 december 2017 13:42:59 CET schreef BWC Illmensee GmbH - Ralph
Gauer:
> My latest test with this service on a Rasberry Pi 3B, with tha latest > aarch64 image, shows that it is not working. After a reboot the > journal > always starts with date/times Oct 26 14:29:36 and only after NTP > becomes > active, which is after the network is active, the date/time becomes > the > current time. > > For now fake-hwclock does a better job.
On a Rpi2 and a Rpi1 the systemctl-timesyncd *does* its work. I activated it after reading this discussion. It changes the time from the kernel build-time to its saved time even before the fake-hwclock comes to work (I had both active at first). The root file system is mounted with "/dev/mmcblk0p2 / ext4 acl,user_xattr,noatime,commit=120 1 1". Perhaps you have some other options active that interfere with saving the time in the inode attributes?
Not that I am aware off. I only did some basic installation stuff. Did enable systemd-timesyncd.service, even started it, but after a reboot the date/time only changes after NTP becomes active. /etc/fstab looks like follows: /dev/disk/by-id/mmc-SD08G_0x7c498e75-part2 / ext4 noatime,nobarrier 1 1 /dev/disk/by-id/mmc-SD08G_0x7c498e75-part1 /boot/efi vfat defaults 0 0 /dev/disk/by-id/mmc-SD08G_0x7c498e75-part3 swap swap defaults 0 0 Command mount shows for / /dev/mmcblk0p2 on / type ext4 (rw,noatime,nobarrier,data=ordered)
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org