Pytanie:
Jak mogę opóźnić uruchomienie usług systemd do czasu ustawienia daty i godziny (brak RTC na Raspberry Pi)
monok
2019-02-25 19:20:02 UTC
view on stackexchange narkive permalink

Kiedy zamykam i wyłączam Raspberry Pi 3b, a następnie włączam go ponownie następnego dnia, podczas sprawdzania sudo systemctl status DustSensor wyświetla się błędna data / godzina rozpoczęcia. Wydrukowana data / godzina pochodzi z daty / godziny zamknięcia.

Jak mogę opóźnić uruchomienie usług do czasu skorygowania daty / godziny z NTP?

Podczas zamykania i wyłącz:

  23 lutego 21:09:24 rp3b systemd [1]: Zatrzymywanie usługi DustSensor.service ...  

Podczas uruchamiania (włączanie ) następnego dnia, jeszcze ok. stara data / godzina:

  23 lutego 21:09:35 rp3b systemd [1]: Uruchomiono usługę DustSensor.service.  

Nieco później data / czas jest poprawiany, ale sudo systemctl status DustSensor podaje starą datę / godzinę (nie pokazano tutaj):

  23 lutego 21:09:51 rp3b systemd [826 ]: Uruchomiono magistralę komunikatów użytkownika magistrali D-Bus.Lut 24 09:17:48 rp3b systemd [1]: Czas został zmieniony 24 lutego 09:17:48 rp3b systemd-timesyncd [277]: Zsynchronizowano z serwerem czasu [2a01: 4f8: c17: b8f :: 2]: 123 (2.debian.pool.ntp.org) .Feb 24 09:17:48 rp3b systemd [1]: apt-daily.timer: Dodanie losowego czasu 1h 24min 33,643221s.Lut 24 09:17:48 rp3b systemd [1]: apt-daily-upgrade.timer: Dodanie losowego czasu 22 min. 10,691517 s. 24 lutego 09:17:48 rp3b systemd [826]: Czas został zmieniony 24 lutego 09:17:48 rp3b systemd [1]: Sieć docelowa osiągnięta jest w trybie online.  

Oto mój plik DustSensor.service:

  [Service] ExecStart = / home / pi / SDS011_Feinstaub_Sensor .pyWorkingDirectory = / home / piRestart = alwaysStandardOutput = syslogStandardError = sysl ogSyslogIdentifier = DustSensorUser = piGroup = pi [Install] WantedBy = multi-user.target  

Z sugestią i przykładem hello.service:

  [Jednostka ] Opis = Witaj po czasie SyncAfter = time-sync.target [Usługa] Type = oneshotRemainAfterExit = yesExecStart = / bin / echo "$ (date) Witaj, właśnie rozpoczęto" [Install] WantedBy = multi-user.target  

Dostaję to, gdzie dopiero po uruchomieniu hello.service data / czas są aktualizowane

  dziennikctl -b | egrep '(ello | anged | ync)' 28 lutego 10:48:54 rp3b systemd [1]: Rozpoczynanie synchronizacji czasu sieciowego ... 28 lutego 10:48:55 rp3b systemd [1]: Rozpoczęto synchronizację czasu sieciowego.Lut 28 10:48:55 rp3b systemd [1]: Osiągnięto cel Zsynchronizowano czas systemowy. 28 lutego 10:49:00 rp3b systemd [1]: Uruchamianie Hello po synchronizacji czasu ... 28 lutego 10:49:00 rp3b systemd [1] : Rozpoczęto Hello After Time Sync.Luty 28 10:49:11 rp3b bluetoothd [570]: Nie udało się uzyskać uchwytów dla charakterystyki „Zmiana usługi” 28 lutego 11:35:51 rp3b systemd [1]: Czas został zmieniony 28 lutego 11:35 : 51 rp3b systemd [499]: Czas został zmieniony Lut 28 11:35:51 rp3b systemd-timesyncd [271]: Zsynchronizowano z serwerem czasu [2a02: 2028: ff01: 14 :: 13]: 123 (2.debian.pool .ntp.org).  

Również to pokazuje zły czas rozpoczęcia:

  sudo systemctl status hello \ u25cf hello.service - Hello After Time Sync Loaded : załadowano (/etc/systemd/system/hello.service; włączone; ustawienie dostawcy: włączone) Aktywne: aktywne (wyjście) od czw. 2019-02-28 10:49:00 CET; 1h 16min temu Proces: 355 ExecStart = / bin / echo $ (data) Witaj świecie, właśnie rozpoczęto (kod = wyjście, status = 0 / SUKCES) Główny PID: 355 (kod = wyjście, status = 0 / SUKCES) CGroup: / system.slice / hello.serviceFeb 28 10:49:00 rp3b systemd [1]: Uruchamianie Hello After Time Sync ... 28 lutego 10:49:00 rp3b systemd [1]: Rozpoczęto Hello After Time Sync.  
Trzy odpowiedzi:
#1
+11
jarondl
2019-03-11 04:15:44 UTC
view on stackexchange narkive permalink

Właściwa funkcja została dodana do systemd w https://github.com/systemd/systemd/pull/8494, która jest zawarta w wersji 239

Zobacz dokumentację w [ 1]:

systemd-time-wait-sync to usługa systemowa, która opóźnia rozpoczęcie jednostek zależnych od time-sync.target do czas systemowy został zsynchronizowany z dokładnym źródłem czasu przez systemd-timesyncd.service.

Oznacza to, że musisz włączyć jednocześnie systemd-time-wait-sync i Wants=time-sync.target

[1] https://www.freedesktop.org/software/systemd/man/systemd- time-wait-sync.service.html

Dzięki, dobrze wiedzieć. Użyjemy go z następnym Raspbian Buster. Raspbian Stretch nadal używa systemd 232 :-(
„Wants = time-sync.target” i dodaj także „After = time-sync.target”. Jeśli nie, obie jednostki są uruchamiane w tym samym czasie, ale nie cel przed sinkronizacją czasu, to jest klucz. Sprawdź to za pomocą "systemd-analysis plot"> output.svg "sekwencji startowej.
#2
+10
Ingo
2019-02-26 00:27:45 UTC
view on stackexchange narkive permalink

AKTUALIZACJA:
Zwróć uwagę na odpowiedź z @jarondl . Dostępna jest nowa usługa systemd-time-wait-sync , z której możemy korzystać od wersji Raspbian Buster .


Aby zsynchronizować się z usługą czasu istnieje specjalny element time-sync.target . W man systemd.special znajdziesz:

time-sync.target
Usługi odpowiedzialne za synchronizację zegara systemowego ze zdalnego źródła (takiego jak klient NTP implementacje) powinny przyciągnąć ten cel i uporządkować się przed nim. Wszystkie usługi, w których niezbędny jest poprawny czas, powinny być zamawiane po tej jednostce, ale nie należy jej pobierać. Systemd automatycznie dodaje zależności typu After = dla tej jednostki docelowej do wszystkich jednostek usługowych skryptów inicjalizacyjnych SysV z nagłówkiem LSB odnoszącym się do „$ time” ułatwienie.

Ale to niewiele pomaga, ponieważ służy tylko do inicjowania usługi synchronizacji czasu. Po uruchomieniu potrzebuje trochę czasu, aby połączyć się z serwerem czasu i zsynchronizować z nim zegar. systemd-timesyncd.service powiadamia o tym menedżera systemowego, więc w dzienniku znajdziesz coś takiego:

  systemd-timesyncd [403]: Zsynchronizowano z czasem serwer 144.76.60.190:123 (2.debian.pool.ntp.org).  

Szukałem systemd-notify , czy możemy uruchomić jednostkę w zależności od na tym powiadomieniu, ale nic nie znalazłem. Więc zajrzę do dziennika, jeśli znajdę powiadomienie. W przeciwnym razie urządzenie nie uruchomi się, ale po pewnym czasie uruchomi się ponownie i spróbuje ponownie. Zmodyfikuj jednostkę tak, aby wyglądała następująco:

  [Jednostka] Opis = SDS011 Feinstaub SensorAfter = time-sync.target [usługa] Restart = on-failureRestartSec = 30ExecStartPre = / bin / bash -c '/ bin / journalctl -b -u systemd-timesyncd | / bin / grep -q "systemd-timesyncd. * Zsynchronizowano z serwerem czasu" 'ExecStart = / home / pi / SDS011_Feinstaub_Sensor.pyWorkingDirectory = / home / piSyslogIdentifier = DustSensorUser = piGroup = pi [Install] WantedBy = multi-user.t

Nie potrzebujesz StandardOutput = syslog i StandardError = syslog . To jest domyślne.

Niestety, to nie pomogło: `27 lutego 09:05:01 rp3b systemd [1]: Uruchomiono DustSensor.` nadal występuje przed` 27 lutego 09:46:11 rp3b systemd [1]: Czas został zmieniony` w wyniku udawanie, że usługa została uruchomiona 45 minut temu, podczas gdy system został uruchomiony 5 minut temu.
@monok Podczas badania, dlaczego Twoja usługa nie uruchamia się po synchronizacji czasu, odkryłem, że istnieje specjalny cel. Zatem użycie argumentu „systemd-timesyncd.service” nie było właściwą zależnością. Zaktualizowałem odpowiedź.
Tym razem się nie zaczyna. Widzę „27 lutego 14:01:24 rp3b systemd-timesyncd [277]: Zsynchronizowano z serwerem czasu [2a02: c205: 2009: 8290 :: 1]: 123 (2.debian.pool.ntp.org).”. Czy ma to związek z brakującym celem. Chce? Widzę, kiedy wykonuję polecenie `ls timers.target.wants``apt-daily.timer apt-daily-upgrade.timer`
@monok Nie, w dokumencie jest napisane: „* Wszystkie usługi, w których niezbędny jest prawidłowy czas, powinny być zamawiane po tej jednostce, ale nie ściągaj jej. *” „Pull in” oznacza „Wants =„ i nie powinno się tego ** ** używać dla usług uruchamianych po synchronizacji czasu. Jak widzisz, usługa synchronizacji czasu jest uruchomiona i nie potrzebuje opcji „Wants =”. Co widzisz z argumentem `systemctl status DustSensor.service`, dlaczego się nie uruchamia? Zaktualizowałem odpowiedź za pomocą jednostki testowej, której użyłem do weryfikacji.
w moim poprzednim poście nie miałem racji mówiąc, że usługa nie została uruchomiona. Został uruchomiony, ale zgłoszona data / godzina była nieprawidłowa i nie widziałem wyjścia. Korzystając z twojego przykładu hello, widzę to po ponownym uruchomieniu z `sudo systemctl status hello`:` Aktywny: aktywny (zakończony) od czwartku 2019-02-28 10:49:00 CET; 53min temu` ... `28 lutego 10:49:00 rp3b systemd [1]: Uruchamiam Hello After Time Sync ... 28 lutego 10:49:00 rp3b systemd [1]: Rozpoczęto Hello After Time Sync.`.
@monok „hello.service” został uruchomiony po synchronizacji czasu i jest wykonywany w bieżącej dacie / godzinie, prawda? Czy użyłeś `journalctl -b` i szukałeś hasła` Hello`? Jaki jest teraz problem?
@monok OK Teraz rozumiem problem. Zmodyfikowałem odpowiedź.
#3
+1
Grubby
2019-11-01 16:46:49 UTC
view on stackexchange narkive permalink

Jeśli chcesz zainstalować ntpstat na swoim pi, możesz to zrobić w inny sposób.

Kroki, które następnie musisz wykonać, to:

  • install ntpstat
  • Utwórz skrypt powłoki, który wywołuje ntpstat co sekundę i kończy pracę tylko wtedy, gdy ma kod zakończenia równy 0 (wskazując że czas na urządzeniu połączył się z serwerem czasu i zsynchronizował czas
  • Utwórz usługę onehot systemd, która wykonuje powyższy skrypt powłoki
  • Zmodyfikuj zależną usługę synchronizowaną czasowo, aby działała tylko po uruchomieniu usługi ntpstat

Zainstaluj ntpstat

sudo apt-get install ntpstat

Utwórz skrypt powłoki, który odpytuje ntpstat

/usr/local/bin/check_time_synced.sh

  #! / bin / bashntpstatwhile printf" Czas jeszcze nie zsynchronizowany \ n "sleep 1s ntpstat (($?)) do: doneprintf" Pomyślnie zsynchronizowano czas e. \ n " 

Utwórz systemową usługę onehot, która wywołuje powyższy skrypt

/ etc / systemd / system / ntpsync.service

  [Jednostka] Opis = Sprawdza status demona ntp. Zwróć tylko wtedy, gdy czas został pomyślnie zsynchronizowanyAfter = network-online.targetWants = network-online.target [Service] ExecStart = / usr / local / bin / check_time_synced.shType = oneshot [Install] WantedBy = multi-user.target  

I włącz usługę

sudo systemctl włącz ntpsync.service

Zmodyfikuj własną usługę zależną od daty i czasu aby rozpocząć dopiero po ntpsync.service

  [Unit] Description = Hello After Time SyncAfter = ntpsync.service [Service] Type = oneshotRemainAfterExit = yesExecStart = / bin / echo "$ (data) Witaj świecie, właśnie się uruchomiłem" [Zainstaluj] WantedBy = multi-user.target  

Następnie zrestartuj pi, a Twoja usługa powinna się uruchomić dopiero wtedy, gdy jednostka ma prawidłowy czas.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...