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: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to