diff --git a/man/systemd-timesyncd.service.xml b/man/systemd-timesyncd.service.xml index fcd731fd6f..9ab4af9763 100644 --- a/man/systemd-timesyncd.service.xml +++ b/man/systemd-timesyncd.service.xml @@ -59,9 +59,8 @@ after time-set.target (see systemd.special7 for details) until the local time has been updated from /var/lib/systemd/timesync/clock - (see below) in order to make it roughly monotonic (see above), should this be necessary — for example - because no RTC device is available. It does not delay other units until synchronization with an accurate - reference time sources has been reached. Use + (see below) in order to make it roughly monotonic. It does not delay other units until synchronization + with an accurate reference time sources has been reached. Use systemd-time-wait-sync.service8 to achieve that, which will delay start of units that are ordered after time-sync.target until synchronization to an accurate reference clock is diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 8a98fa4c0f..e731c9ced2 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -1018,7 +1018,7 @@ systemd-timesyncd.service8 service is a simple daemon that pulls in this target and orders itself before it. Besides implementing the SNTP network protocol it maintains a timestamp file on disk whose modification - time is regularlary updated. At service start-up the local system clock is updated accordingly, + time is regularlary updated. At service start-up the local system clock is set from that modification time, ensuring it increases roughly monotonically. Note that ordering a unit after time-set.target only has effect if @@ -1026,7 +1026,7 @@ monotonicity. Otherwise, this target might get reached before the clock is adjusted to be roughly monotonic. Enable systemd-timesyncd.service8, - to achieve that — or an alternative NTP implementation. + or an alternative NTP implementation to delay the target. @@ -1043,9 +1043,9 @@ OnCalendar= directive. This target provides stricter clock accuracy guarantees than - time-set.target (see above), but likely relies on possibly unreliable - network communication and thus might introduce possibly substantial activation delays for - services ordered after this target. Services that require clock accuracy and where network + time-set.target (see above), but likely requires + network communication and thus introduces unpredictable delays. + Services that require clock accuracy and where network communication delays are acceptable should use this target. Services that require a less accurate clock, and only approximate and roughly monotonic clock behaviour should use time-set.target instead. @@ -1057,7 +1057,7 @@ systemd-timesyncd.service8, enable systemd-time-wait-sync.service8 - to achieve that; or use an equivalent service for other NTP implementations. + to delay the target; or use an equivalent service for other NTP implementations. Comparison