[vz-users] Raspbian stretch: vzlogger und Systemzeit

[Rupert Schöttler]

Hallo Udo,

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.


Am 26.03.2018 um 20:14 schrieb Udo1:
> Am 26.03.2018 um 18:25 schrieb Rupert Schöttler:
>> Hilft nix. Artefakt erscheint wie vorher.
> check das mal hier:
> https://wiki.archlinux.org/index.php/systemd-timesyncd

Was meinst Du konkret? Mir sagen die Hinweise nur, dass die
Zeitsynchronisation funktioniert:

pi at ras2:~ $ timedatectl status
      Local time: Di 2018-03-27 12:57:05 CEST
  Universal time: Di 2018-03-27 10:57:05 UTC
        RTC time: n/a
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

> Außerdem kann in raspi-config ausgewählt werden wann network aktiv wird.

Meinst Du:
Waiting for network on boot is enabled
? --> Hilft auch nix.


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

pi at ras2:~ $ grep -iE "(vzlogg|time)" /var/log/syslog
Mar 27 12:35:58 ras2 systemd[1]: Starting Network Time Synchronization...
Mar 27 12:35:58 ras2 systemd[1]: Started Network Time Synchronization.
Mar 27 12:35:58 ras2 systemd[1]: Reached target System Time Synchronized.
Mar 27 12:35:58 ras2 systemd[1]: apt-daily.timer: Adding 1h 32min
35.694948s random time.
Mar 27 12:35:58 ras2 systemd[1]: apt-daily-upgrade.timer: Adding 9min
6.792650s random time.
Mar 27 12:35:58 ras2 systemd[1]: Reached target Timers.
Mar 27 12:35:58 ras2 kernel: [    0.000070] clocksource: timer: mask:
0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
Mar 27 12:35:58 ras2 kernel: [    0.000169] bcm2835: system timer (irq = 27)
Mar 27 12:35:58 ras2 kernel: [    0.272855] clocksource: Switched to
clocksource timer
Mar 27 12:35:58 ras2 kernel: [    0.353523] workingset:
timestamp_bits=14 max_order=17 bucket_order=3
Mar 27 12:35:58 ras2 kernel: [    0.990663] bcm2835-wdt
20100000.watchdog: Broadcom BCM2835 watchdog timer
Mar 27 12:36:09 ras2 systemd[1]: Started vzlogger.
Mar 27 12:36:18 ras2 systemd[1]: apt-daily.timer: Adding 11h 46min
24.802322s random time.
Mar 27 12:36:18 ras2 systemd[1]: apt-daily.timer: Adding 3h 17min
11.999063s random time.
Mar 27 12:36:37 ras2 systemd[1]: Time has been changed
Mar 27 12:36:37 ras2 systemd[1]: apt-daily-upgrade.timer: Adding 37min
36.288257s random time.
Mar 27 12:36:37 ras2 systemd-timesyncd[212]: Synchronized to time server
193.219.28.147:123 (2.debian.pool.ntp.org).
Mar 27 12:36:37 ras2 systemd[1]: apt-daily.timer: Adding 7h 48min
24.140887s random time.
Mar 27 12:37:28 ras2 systemd[1]: dev-serial1.device: Job
dev-serial1.device/start timed out.
Mar 27 12:37:28 ras2 systemd[1]: Timed out waiting for device
dev-serial1.device.
Mar 27 12:37:28 ras2 systemd[1]: dev-serial1.device: Job
dev-serial1.device/start failed with result 'timeout'.
Mar 27 12:37:44 ras2 systemd[641]: Reached target Timers.
Mar 27 12:57:05 ras2 dbus[247]: [system] Activating via systemd: service
name='org.freedesktop.timedate1'
unit='dbus-org.freedesktop.timedate1.service'
Mar 27 12:57:05 ras2 systemd[1]: Starting Time & Date Service...
Mar 27 12:57:05 ras2 dbus[247]: [system] Successfully activated service
'org.freedesktop.timedate1'
Mar 27 12:57:05 ras2 systemd[1]: Started Time & Date Service.

vzlogger wird um 12:36:09 gestartet, um 12:36:37 wird die Uhrzeit
geändert. Genau hier entsteht der Sprung bzw. das "Artefakt".

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?

Das time-sync.target sollte doch genau das machen, siehe
https://manpages.debian.org/stretch/systemd/systemd.special.7.en.html:
time-sync.target
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 /After=/for this target unit to
all SysV init script service units with an LSB header referring to the
"$time" facility.

NEIN, genau das macht dieses Target nicht, auch wenn es sich so anhört,
siehe
https://github.com/systemd/systemd/issues/5097#issuecomment-319505769.
Die Entwickler haben wohl einen

|systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized|

eingeführt, der aber wohl standardmäßig -- oder nur bei mir -- nicht da
ist:
pi at ras2:~ $ systemctl status systemd-time-wait-sync
Unit systemd-time-wait-sync.service could not be found.
Werde mal weiter suchen und ggf. einen Patch einspielen.

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?

Danke & Viele Grüße
Rupert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20180327/577749bf/attachment.html>