Po po téměř roce vývoje od vydání verze 5.38 byla vydána nová stabilní verze 5.40 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 75 vývojářů. Změněno bylo přibližně 160 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Uroš Popović popisuje, jak si nastavit Linux na desce jako Raspberry Pi Zero, aby je šlo používat jako USB „flešku“.
Andreas Kling oznámil, že jelikož už se nevěnuje nezávislému operačnímu systému SerenityOS, ale výhradně jeho webovému prohlížeči Ladybird, přičemž vyvíjí primárně na Linuxu, SerenityOS opustí a Ladybird bude nově samostatný projekt (nový web, repozitář na GitHubu).
Po dvou měsících vývoje byla vydána nová verze 0.13.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 73 vývojářů. Přehled novinek v poznámkách k vydání.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Řeším podivný problém. Mému serveru s Gentoo (Linux 4.10.13) se předbíhá čas. Dělá to asi 6 sekund za 120 dnů, takže nejde o nic super vážného. Jde ale o to, že ntpd není schopné čas udržet synchronizovaný. Po vypnutí ntpd nefunguje ani ruční synchronizace, i když zdánlivě uspěje:
zeus ~ # ntpdate tik.cesnet.cz 29 Aug 20:04:30 ntpdate[683]: step time server 195.113.144.201 offset -6.648793 sec zeus ~ # ntpdate tik.cesnet.cz 29 Aug 20:04:38 ntpdate[2367]: step time server 195.113.144.201 offset -6.646034 sec zeus ~ # ntpdate tik.cesnet.cz 29 Aug 20:04:49 ntpdate[4475]: step time server 195.113.144.201 offset -6.636047 sec
Pokud se (při vypnutém ntpd) pokusím ručně změnit čas na něco v minulosti, příkaz uspěje, ale změna se neprojeví:
zeus ~ # date -s "2017-08-29 19:00:00" Út srp 29 19:00:00 CEST 2017 zeus ~ # date Út srp 29 20:09:42 CEST 2017
I ve výpisu strace
je vidět úspěšné systémové volání. Ze zoufalství jsem zkusil změnit čas na něco v budoucnosti a pak už to nešlo vrátit zpátky. Musel jsem restartovat server (a zabránit uložení do HW hodin).
Nejdřív jsem to bral jako divnou odchylku na serveru, ale pak jsem zjistil, že nemožnost vrátit čas zpět se projevuje i na mém notebooku (s Debianem). To tedy znamená, že i příklad na Debian Wiki je naprosto nefunkční. Nešlo to ani s jádrem ve Stable, ani v Testingu.
Mám tu ještě jeden, starší systém s Gentoo a Linuxem 4.7.4. Tam změna data/času do minulosti funguje. Hodil jsem tam Linux 4.12.7 a stále to funguje. Pak jsem zkusil jeden starší laptop s Debianem Stable a změna data rovněž funguje.
Takže když to shrnu, tak to nevypadá na bug v Linuxu, ale na problém s konkrétními modely CPU. Konkrétně na těchto CPU mi prostě nejde nastavit čas do minulosti:
Sním či bdím? WTF? Děje se vám to taky?
Řešení dotazu:
ntpdc
na novějších jádrech se už se serverem nespojuje (hlavně díky CVE-2013-5211) a ntpq
to přebírá, ale na starší jádrech se s tím dalo dělat více.) Zajímavé jsou přikazy ntpq kerninfo, sysinfo, sysstats
. Mě se něco podobného přihodilo před lety, ale byla nějaká virutalizační situace s XENem. ntpdaemon nedokázal předat info hodinám, konstanty pll offset
a pll frequency
byly na nule v kerninfo
ntpq> kerninfo associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect, pll offset: 0 pll frequency: -6.86299 maximum error: 16 estimated error: 16 kernel status: pll unsync nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter: 0 calibration interval 0 calibration cycles: 0 jitter exceeded: 0 stability exceeded: 0 calibration errors: 0sysinfo:
ntpq> sysinfo associd=0 status=c018 leap_alarm, sync_unspec, 1 event, no_sys_peer, system peer: 0.0.0.0:0 system peer mode: unspec leap indicator: 11 stratum: 16 log2 precision: -23 root delay: 0.000 root dispersion: 1.425 reference ID: STEP reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system jitter: 0.000119 clock jitter: 0.000 clock wander: 0.000 broadcast delay: -50.000 symm. auth. delay: 0.000sysstats:
ntpq> sysstats uptime: 32032 sysstats reset: 32032 packets received: 3709 current version: 3582 older version: 106 bad length or format: 0 authentication failed: 0 declined: 0 restricted: 0 rate limited: 0 KoD responses: 0 processed for time: 2568
system peer:
a položka reference ID: STEP
znamená že si jedeš hodiny za své. Co máš v /etc/ntp.conf
? jaké tam jsou servery? Co dostaneš příkazem ntpq -c pe
a ntpq -c as
?
normální sysinfo je
ntpq -c sysi associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, system peer: netopyr.hanacke.net:123 system peer mode: client leap indicator: 00 stratum: 2 log2 precision: -23 root delay: 12.184 root dispersion: 8.292 reference ID: 94.124.107.190 reference time: dd512051.ee64b64e Wed, Aug 30 2017 13:30:25.931 system jitter: 4.910560 clock jitter: 6.812 clock wander: 0.072 broadcast delay: -50.000 symm. auth. delay: 0.000tedy definovaný peer (server odkud bereš čas), stratum 16 znamená že jsi bez spojení. Zkontroluj firewall.
adjtimex
na nulu, výsledek je tento:
zeus ~ # ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== *tik.cesnet.cz 195.113.144.238 2 u 1 64 17 18.820 -5255.7 1.758 +ntp1.tdc.fi .GPS. 1 u 5 64 17 60.445 -5255.4 0.927 +time.shf.uk.as4 193.150.34.2 3 u 2 64 17 57.138 -5254.2 0.848 -test.diarizer.c 218.73.139.35 2 u 2 64 17 188.613 -5262.8 1.374 -ntp.katho.be 193.190.230.66 2 u 7 64 17 47.147 -5251.6 1.036 zeus ~ # ntpq -c as ind assid status conf reach auth condition last_event cnt =========================================================== 1 11218 961a yes yes none sys.peer sys_peer 1 2 11219 941a yes yes none candidate sys_peer 1 3 11220 9424 yes yes none candidate reachable 2 4 11221 9354 yes yes none outlier reachable 5 5 11222 93b4 yes yes none outlier reachable 11 zeus ~ # ntpq -c kerni associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect, pll offset: 0 pll frequency: -6.86299 maximum error: 16 estimated error: 16 kernel status: pll unsync nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter: 0 calibration interval 0 calibration cycles: 0 jitter exceeded: 0 stability exceeded: 0 calibration errors: 0 zeus ~ # ntpq -c sysi associd=0 status=c613 leap_alarm, sync_ntp, 1 event, spike_detect, system peer: tik.cesnet.cz:123 system peer mode: client leap indicator: 11 stratum: 3 log2 precision: -20 root delay: 19.598 root dispersion: 6202.090 reference ID: 195.113.144.201 reference time: dd51238c.4b60ead8 Wed, Aug 30 2017 13:44:12.294 system jitter: 1.522854 clock jitter: 0.001 clock wander: 0.000 broadcast delay: -50.000 symm. auth. delay: 0.000Takže peer už mám, ale čas je nadále nesynchronizovaný. V
ntp.conf
je toto:
server tik.cesnet.cz prefer server 0.gentoo.pool.ntp.org server 1.gentoo.pool.ntp.org server 2.gentoo.pool.ntp.org server 3.gentoo.pool.ntp.org driftfile /var/lib/ntp/ntp.drift restrict default kod nomodify notrap nopeer restrict -6 default kod nomodify notrap nopeer restrict 127.0.0.1 restrict 10.10.10.0 mask 255.255.255.0 nomodify nopeer notrap
ntpdate
nebo date -s
kolikrát chci a čas se nezmění.
Dokonce jsem si napsal vlastní program, co zavolá settimeofday()
a hned poté gettimeofday()
a ten čas předaný do settimeofday()
se prostě nenastaví, pokud je menší než aktuální čas.
ntpq -c kerni associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, pll offset: -46.5091 pll frequency: -31.1978 maximum error: 0.53388 estimated error: 0.016335 kernel status: pll nano mode=fll pll time constant: 10 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter: 0 calibration interval 0 calibration cycles: 0 jitter exceeded: 0 stability exceeded: 0 calibration errors: 0pll offset znamená o kolik milisekud (46) si ntpd, myslí že čas je blbe. A pll frequency znamená o kolik mění mnitřní hodiny, aby se dostal do souhlasu s časem z peeru v jednotká ppm part per milion, takže u mne zhruba zpomalí hodiny o 31 mikrosekundy každou sekundu. (a než dopisuji mail tak offset se mi blíží nule a je na -39) a tobě si myslí ntpd že je čas správně, ofset nula a tak žádné modifikace nedělá. Nejaký debug režim ntpd serveru.
strace ntpd -qgddd
a zde je vidět, že čas je alespoň na chvíli přenastaven:
clock_gettime(CLOCK_REALTIME, {tv_sec=1504096155, tv_nsec=632066676}) = 0 clock_settime(CLOCK_REALTIME, {tv_sec=1504096150, tv_nsec=569906000}) = 0 ... write(1, "ntpd: time set -5.062161s\n", 26ntpd: time set -5.062161s ) = 26 clock_gettime(CLOCK_REALTIME, {tv_sec=1504096150, tv_nsec=570400825}) = 0Jenže když to spustím znovu, tak je čas stále o 5 sekund mimo. To skoro vypadá, jako by mi v systému běžel ještě nějaký další hajzldémon, co si s časem dělá, co chce, a vrací zpět všechny pohyby času do minulosti.
Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
. Tím intelem to nebude.
rtc_cmos
, v /proc/driver/rtc
jsou prakticky stejné údaje.
/sys/devices/system/clocksource/clocksource0/current_clocksource
mám tsc
, ale změna třeba na acpi_pm
k ničemu nevedla.
/sys/devices/system/clocksource/clocksource0/available_clocksource
se vybere ten prvni, pokud neni nestabilni nebo neco
Samozrejeme toto je nezmysel
NTP silno zavisi na CPU, krasne sa to prejavuje vo vmware kde aj ked hypervisory su rovnake, jednotlive CPu maju mierne rozlisnu frekvenciu a po premigrovani chvilu ntpcku trva kym si "zykne" na novy CPU
odporucam precitat http://support.ntp.org/bin/view/Support/KnownHardwareIssues
D>
Tiskni Sdílej: