18 Dec
2017
18 Dec
'17
08:55
With "after boot" I meant "manually". Ralph Gauer Am 18.12.2017 um 09:51 schrieb BWC Illmensee GmbH - Ralph Gauer: > 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 > > 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. > > > Ralph Gauer > > 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) >> > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org