[opensuse-arm] Packet fake-hwclock generated
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock. The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot. On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting. Hope this is accepted to be included. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
Does this offer anything beyond what systemd-timesyncd offers? Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Freek, Am 06.12.2017 um 15:23 schrieb Freek de Kruijf:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
You forgot to mention the link or request number you want us to accept. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op woensdag 6 december 2017 16:24:25 CET schreef Andreas Färber:
Hi Freek,
Am 06.12.2017 um 15:23 schrieb Freek de Kruijf:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
You forgot to mention the link or request number you want us to accept.
Cheers, Andreas
Request 554811 -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op woensdag 6 december 2017 15:58:38 CET schreef Brüns, Stefan:
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
Does this offer anything beyond what systemd-timesyncd offers?
Don't know. I would expect, if this does the same as this package, by default to be included in images for systems without a Real Time Clock. I did not notice such a inclusion, but I struggled with dates Jan 1, 1970 after starting a Raspberry Pi using openSUSE, before NTP finally set the time proper. This packet sets the time very early in the boot process so times are beyond times last used before the system went down, at least after a proper shutdown. After a crash this time might be off less than one hour. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wednesday, December 6, 2017 11:58:16 PM CET Freek de Kruijf wrote:
Op woensdag 6 december 2017 15:58:38 CET schreef Brüns, Stefan:
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
Does this offer anything beyond what systemd-timesyncd offers?
Don't know. I would expect, if this does the same as this package, by default to be included in images for systems without a Real Time Clock. I did not notice such a inclusion, but I struggled with dates Jan 1, 1970 after starting a Raspberry Pi using openSUSE, before NTP finally set the time proper. This packet sets the time very early in the boot process so times are beyond times last used before the system went down, at least after a proper shutdown. After a crash this time might be off less than one hour.
systemctl-timesyncd is not enabled by default (probably it should on e.g. the RPi images). Time will be saved to persistent storage on regular intervals after time has been set up from a reliable timesource - that is either NTP, or manually set with timedatectl. The timestamp file is also saved when timesyncd is stopped, i.e. on system shutdown. Contrary to the fake-hwclock script, it does not spawn external processes on each update, and it does not write the timestamp to the file but just uses the mtime inode field, so less writes on each update. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Op donderdag 7 december 2017 01:05:18 CET schreef Stefan Brüns:
On Wednesday, December 6, 2017 11:58:16 PM CET Freek de Kruijf wrote:
Op woensdag 6 december 2017 15:58:38 CET schreef Brüns, Stefan:
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
Does this offer anything beyond what systemd-timesyncd offers?
Don't know. I would expect, if this does the same as this package, by default to be included in images for systems without a Real Time Clock. I did not notice such a inclusion, but I struggled with dates Jan 1, 1970 after starting a Raspberry Pi using openSUSE, before NTP finally set the time proper. This packet sets the time very early in the boot process so times are beyond times last used before the system went down, at least after a proper shutdown. After a crash this time might be off less than one hour.
systemctl-timesyncd is not enabled by default (probably it should on e.g. the RPi images).
It definitely should. I made a bug report on it: https://bugzilla.suse.com/show_bug.cgi?id=1071763 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
That is strange. Independent of architecture openSUSE used to have code in the initrd that made sure that the system's time is set to at least the time when the initrd was created. Maybe that code got lost somehow? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op vrijdag 8 december 2017 14:40:12 CET schreef Ludwig Nussel:
Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot. That is strange. Independent of architecture openSUSE used to have code in the initrd that made sure that the system's time is set to at least the time when the initrd was created. Maybe that code got lost somehow?
No, it is there, and the remark about Jan 1, 1970 is from the time before that change. However, this time is used each time the system starts, which causes log entries with dates/times that are far from the real time and which, at least after a proper shutdown, should be later than the date/times used just before the shutdown. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Op donderdag 7 december 2017 14:08:56 CET schreef Freek de Kruijf:
Op donderdag 7 december 2017 01:05:18 CET schreef Stefan Brüns:
On Wednesday, December 6, 2017 11:58:16 PM CET Freek de Kruijf wrote:
Op woensdag 6 december 2017 15:58:38 CET schreef Brüns, Stefan:
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included.
Does this offer anything beyond what systemd-timesyncd offers?
Don't know. I would expect, if this does the same as this package, by default to be included in images for systems without a Real Time Clock. I did not notice such a inclusion, but I struggled with dates Jan 1, 1970 after starting a Raspberry Pi using openSUSE, before NTP finally set the time proper. This packet sets the time very early in the boot process so times are beyond times last used before the system went down, at least after a proper shutdown. After a crash this time might be off less than one hour.
systemctl-timesyncd is not enabled by default (probably it should on e.g. the RPi images).
It definitely should. I made a bug report on it: https://bugzilla.suse.com/show_bug.cgi?id=1071763
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. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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? Ralph Gauer Am 11.12.2017 um 13:25 schrieb Freek de Kruijf:
Op donderdag 7 december 2017 14:08:56 CET schreef Freek de Kruijf:
Op donderdag 7 december 2017 01:05:18 CET schreef Stefan Brüns:
Op woensdag 6 december 2017 15:58:38 CET schreef Brüns, Stefan:
On Mittwoch, 6. Dezember 2017 15:23:19 CET Freek de Kruijf wrote:
In Raspbian I noticed a packet always included in the image called fake- hwclock. I used the tar.gz file together with a .spec file to generate this packet for openSUSE distributions for systems without a Real Time Clock.
The description is: Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform file system checks at every boot.
On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.
Hope this is accepted to be included. Does this offer anything beyond what systemd-timesyncd offers? Don't know. I would expect, if this does the same as this package, by default to be included in images for systems without a Real Time Clock. I did not notice such a inclusion, but I struggled with dates Jan 1, 1970 after starting a Raspberry Pi using openSUSE, before NTP finally set the time proper. This packet sets the time very early in the boot process so times are beyond times last used before the system went down, at least after a proper shutdown. After a crash this time might be off less than one hour. systemctl-timesyncd is not enabled by default (probably it should on e.g.
On Wednesday, December 6, 2017 11:58:16 PM CET Freek de Kruijf wrote: the RPi images). It definitely should. I made a bug report on it: https://bugzilla.suse.com/show_bug.cgi?id=1071763 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.
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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) -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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
systemd-timesyncd conflicts with ntpd. So if a ntpd service is needed, fake-hwclock is the better choice for time correction on boot. Ralph Gauer 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
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
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
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
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
So, for myself, I will keep using fake-hwclock in combination with ntpd (used as server, too) and a cron job "fake-hwclock save" for saving time once a week (to preserve the health of the micro-sd-card). Ralph Gauer Am 18.12.2017 um 10:01 schrieb Stefan Brüns:
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)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Andreas Färber -
Brüns, Stefan -
BWC Illmensee GmbH - Ralph Gauer -
Freek de Kruijf -
Ludwig Nussel -
Stefan Brüns