<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hallo Udo,</p>
<p>wenn das Folgende wirkt wie experimentelle Datenverarbeitung oder
Erfahrungsbericht zu "Jugend forscht", dann liegt das daran, dass
ich parallel zum Schreiben recherchiert habe und -- meine
Erfahrungen und Erkenntnisse zusammenschreibe :-). Vielleicht
hilft es anderen.<br>
</p>
<br>
<div class="moz-cite-prefix">Am 26.03.2018 um 20:14 schrieb Udo1:<br>
</div>
<blockquote type="cite"
cite="mid:fd84c94c-1c9f-ac06-e189-d2768dd24f2c@gmx.net">Am
26.03.2018 um 18:25 schrieb Rupert Schöttler:
<br>
<blockquote type="cite">Hilft nix. Artefakt erscheint wie vorher.
<br>
</blockquote>
check das mal hier:
<br>
<a class="moz-txt-link-freetext" href="https://wiki.archlinux.org/index.php/systemd-timesyncd">https://wiki.archlinux.org/index.php/systemd-timesyncd</a>
<br>
</blockquote>
<br>
Was meinst Du konkret? Mir sagen die Hinweise nur, dass die
Zeitsynchronisation funktioniert:<br>
<br>
<tt>pi@ras2:~ $ timedatectl status</tt><tt><br>
</tt><tt> Local time: Di 2018-03-27 12:57:05 CEST</tt><tt><br>
</tt><tt> Universal time: Di 2018-03-27 10:57:05 UTC</tt><tt><br>
</tt><tt> RTC time: n/a</tt><tt><br>
</tt><tt> Time zone: Europe/Berlin (CEST, +0200)</tt><tt><br>
</tt><tt> Network time on: yes</tt><tt><br>
</tt><tt>NTP synchronized: yes</tt><tt><br>
</tt><tt> RTC in local TZ: no</tt><tt><br>
</tt><br>
<blockquote type="cite"
cite="mid:fd84c94c-1c9f-ac06-e189-d2768dd24f2c@gmx.net">Außerdem
kann in raspi-config ausgewählt werden wann network aktiv wird.
<br>
</blockquote>
<br>
Meinst Du:<br>
<tt>Waiting for network on boot is enabled</tt><tt><br>
</tt>? --> Hilft auch nix.<br>
<br>
<br>
Das Problem ist. m.E. einfach nur, dass die Reihenfolge der Services
nicht beachtet wird, die mit /etc/systemd/system/vzlogger.service
eingestellt werden soll. Siehe Auszug aus<br>
<br>
<tt>pi@ras2:~ $ grep -iE "(vzlogg|time)" /var/log/syslog</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: Starting Network Time
Synchronization...</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: Started Network Time
Synchronization.</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: Reached target System Time
Synchronized.</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: apt-daily.timer: Adding 1h
32min 35.694948s random time.</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: apt-daily-upgrade.timer:
Adding 9min 6.792650s random time.</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 systemd[1]: Reached target Timers.</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 kernel: [ 0.000070] clocksource:
timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:
1911260446275 ns</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 kernel: [ 0.000169] bcm2835: system
timer (irq = 27)</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 kernel: [ 0.272855] clocksource:
Switched to clocksource timer</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 kernel: [ 0.353523] workingset:
timestamp_bits=14 max_order=17 bucket_order=3</tt><tt><br>
</tt><tt>Mar 27 12:35:58 ras2 kernel: [ 0.990663] bcm2835-wdt
20100000.watchdog: Broadcom BCM2835 watchdog timer</tt><tt><br>
</tt><tt>Mar 27 12:36:09 ras2 systemd[1]: Started vzlogger.</tt><tt><br>
</tt><tt>Mar 27 12:36:18 ras2 systemd[1]: apt-daily.timer: Adding
11h 46min 24.802322s random time.</tt><tt><br>
</tt><tt>Mar 27 12:36:18 ras2 systemd[1]: apt-daily.timer: Adding 3h
17min 11.999063s random time.</tt><tt><br>
</tt><tt>Mar 27 12:36:37 ras2 systemd[1]: Time has been changed</tt><tt><br>
</tt><tt>Mar 27 12:36:37 ras2 systemd[1]: apt-daily-upgrade.timer:
Adding 37min 36.288257s random time.</tt><tt><br>
</tt><tt>Mar 27 12:36:37 ras2 systemd-timesyncd[212]: Synchronized
to time server 193.219.28.147:123 (2.debian.pool.ntp.org).</tt><tt><br>
</tt><tt>Mar 27 12:36:37 ras2 systemd[1]: apt-daily.timer: Adding 7h
48min 24.140887s random time.</tt><tt><br>
</tt><tt>Mar 27 12:37:28 ras2 systemd[1]: dev-serial1.device: Job
dev-serial1.device/start timed out.</tt><tt><br>
</tt><tt>Mar 27 12:37:28 ras2 systemd[1]: Timed out waiting for
device dev-serial1.device.</tt><tt><br>
</tt><tt>Mar 27 12:37:28 ras2 systemd[1]: dev-serial1.device: Job
dev-serial1.device/start failed with result 'timeout'.</tt><tt><br>
</tt><tt>Mar 27 12:37:44 ras2 systemd[641]: Reached target Timers.</tt><tt><br>
</tt><tt>Mar 27 12:57:05 ras2 dbus[247]: [system] Activating via
systemd: service name='org.freedesktop.timedate1'
unit='dbus-org.freedesktop.timedate1.service'</tt><tt><br>
</tt><tt>Mar 27 12:57:05 ras2 systemd[1]: Starting Time & Date
Service...</tt><tt><br>
</tt><tt>Mar 27 12:57:05 ras2 dbus[247]: [system] Successfully
activated service 'org.freedesktop.timedate1'</tt><tt><br>
</tt><tt>Mar 27 12:57:05 ras2 systemd[1]: Started Time & Date
Service.</tt><tt><br>
</tt><br>
vzlogger wird um 12:36:09 gestartet, um 12:36:37 wird die Uhrzeit
geändert. Genau hier entsteht der Sprung bzw. das "Artefakt".<br>
<br>
Oder vielleicht warten die services auch richtig aufeinander im
Sinne einer Start-Reihenfolge, aber nicht darauf, dass time-sync die
Zeit auch richtig eingestellt hat? Könnte man das konfigurieren? <br>
<br>
Das time-sync.target sollte doch genau das machen, siehe <a
moz-do-not-send="true"
href="https://manpages.debian.org/stretch/systemd/systemd.special.7.en.html">https://manpages.debian.org/stretch/systemd/systemd.special.7.en.html</a>:<br>
<tt>time-sync.target
</tt>
<div style="margin-left: 4.00ex;"><tt>Services responsible for
synchronizing the system clock from a remote source (such as NTP
client implementations) should pull in this target and order
themselves before it. All services where correct time is
essential should be ordered after this unit, but not pull it in.
systemd automatically adds dependencies of type </tt><tt><i>After=</i></tt><tt>
for this target unit to all SysV init script service units with
an LSB header referring to the "$time" facility.</tt></div>
<br>
NEIN, genau das macht dieses Target nicht, auch wenn es sich so
anhört, siehe
<a class="moz-txt-link-freetext" href="https://github.com/systemd/systemd/issues/5097#issuecomment-319505769">https://github.com/systemd/systemd/issues/5097#issuecomment-319505769</a>.
Die Entwickler haben wohl einen <br>
<pre><code>systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized</code></pre>
eingeführt, der aber wohl standardmäßig -- oder nur bei mir -- nicht
da ist: <br>
<tt>pi@ras2:~ $ systemctl status systemd-time-wait-sync</tt><tt><br>
</tt><tt>Unit systemd-time-wait-sync.service could not be found.</tt><tt><br>
</tt>Werde mal weiter suchen und ggf. einen Patch einspielen.<br>
<br>
Oder könnte dem vzlogger sagen, dass er etwas warten soll (15 bis 20
sec würden reichen), bevor er mit der Datensammlung anfängt?<br>
<br>
Danke & Viele Grüße<br>
Rupert<br>
</body>
</html>