Vlákno názorů k článku Nebojte se systemd: jednotky od j - Jo, ono se to nejak samo a mozna...

Jo, ono se to nejak samo a mozna to i dela to, co autor pise ... a mozna (spis urcite) taky ne ...

Kdyz budu ja chtit na vzdalenym stroji neco pustit, tak to udelam ssh stroj 'command' a je naprosto jasny co se stane. A dokonce tak umim zadat heslo ( k tomu klici) a umim samosebou spustit i interaktivni appku, ktera se treba na neco zepta. Naprosto univerzalni.

Jinak nevim nic o tom, ze by start ntpd neco jednorazove syncnul, na to se pouziva ntpdate. A vi vlastne buh, jestli by to ntpd (nebo i ntpdate) nastartovalo ... kdyz to pustim normalne, tak je to jisty.

Pravdepodopne proto, ze jak ntpd, tak i systemd-timesyncd.service maji sva omezeni:
ntpd: neumi sync, pokud se rozjede cas o vice nez urcenou hodnotu (1000s default) a neumi to opakovane (viz -g), pro pouziti ntpdate je nutne navic ntpd stopnout
systemd: nema tak jemny drift jako ntpd, nelze pouzit jako ntp server

Ntpd dokaze syncnut cas aj ked je odchylka na stroji akokolvek velka. Prosim dostudovat dokumentaciu. A pohladat si nieco o "tinker panic".

Aha, diky za info, o tomhle jsem dodnes nevedel.

No ja se ted doma bavil s Rpi, ktere pouzivam jako lokalni DNS.
Potreboval jsem delat na rozvodech elektriky, tak jsem ho na par hodin vypnul.
A najednou krasna hlava 22.
Rpi melo pri bootu ujety cas, tak se podivalo do ntp.conf a zkusilo resolvnout vychozi NTP servery z debianiho poolu. Jenze tam je zapnuty DNSSEC, takze resolv neprosel. A DNSSEC nezacne fungovat, dokud se nesyncne cas podle NTP.

Krasne, time deadlock :-D

Tak hlavne ze si v suchu a bezpeci ... ;D.