shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-28 02:50:16 +03:00
Code

man: apply @Minoru's suggestions from code review

Browse Source 
Co-authored-by: Alexander Batischev <eual.jp@gmail.com>
This commit is contained in:
Lennart Poettering 2020-12-28 10:43:10 +01:00
parent b149d230ea
commit 57b3b8f48c
2 changed files with 8 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
man/systemd-timesyncd.service.xml
View File

@ -59,9 +59,8 @@
after <filename>time-set.target</filename> (see
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details) until the local time has been updated from <filename>/var/lib/systemd/timesync/clock</filename>
(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
<citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
to achieve that, which will delay start of units that are ordered after
<filename>time-sync.target</filename> until synchronization to an accurate reference clock is

12
man/systemd.special.xml
View File

@ -1018,7 +1018,7 @@
<citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
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.</para>
<para>Note that ordering a unit after <filename>time-set.target</filename> 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
<citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
to achieve that — or an alternative NTP implementation.</para>
or an alternative NTP implementation to delay the target.</para>
</listitem>
</varlistentry>
<varlistentry>
@ -1043,9 +1043,9 @@
<varname>OnCalendar=</varname> directive.</para>
<para>This target provides stricter clock accuracy guarantees than
<filename>time-set.target</filename> (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
<filename>time-set.target</filename> (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
<filename>time-set.target</filename> instead.</para>
@ -1057,7 +1057,7 @@
<citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
enable
<citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
to achieve that; or use an equivalent service for other NTP implementations.</para>
to delay the target; or use an equivalent service for other NTP implementations.</para>
<table>
<title>Comparison</title>