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