[SOLVED] Debian időszinkron mizéria

Debian GNU/Linux

Sziasztok!

Proxmox Debian alatt szenvedek egy időszinkron hibával...

Linux pve2 5.15.102-1-pve #1 SMP PVE 5.15.102-1 (2023-03-14T13:48Z) x86_64 GNU/Linux

 

Ba van állítva a BIOS órája, teljesen pontosan. be van szinkronizálva a Debian órája, teljesen pontosan (tzdata beállítva).

A hwclock jó időt mutat, a date jó időt mutat. Egész nap figyelem, nem mászik el.

Reggel az fogad, hogy több mint egy héttel hátrébb állt a linux ideje. A hwclock továbbra is jó időt mutat.

root@pve2:~# timedatectl
               Local time: Sat 2023-03-18 09:12:24 CET
           Universal time: Sat 2023-03-18 08:12:24 UTC
                 RTC time: Sat 2023-03-18 08:12:24
                Time zone: Europe/Budapest (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
 

Mi a tőgy történhet éjjel, hogy elcseszi a pontos időt?

A cron-ban nem találok olyan processzt, ami ilyet okozna (másik, jól működő szerverrel hasonlítgatom össze)

A chronny az alábbiakat adja:

chronyc> tracking
Reference ID    : 5100740D (81.0.116.13)
Stratum         : 3
Ref time (UTC)  : Sat Mar 18 08:05:02 2023
System time     : 0.000030574 seconds fast of NTP time
Last offset     : +0.000052732 seconds
RMS offset      : 0.000067810 seconds
Frequency       : 15.745 ppm fast
Residual freq   : +0.003 ppm
Skew            : 0.044 ppm
Root delay      : 0.002224029 seconds
Root dispersion : 0.000851090 seconds
Update interval : 1031.6 seconds
Leap status     : Normal
 

Már kifogytam az ötletekből...

  • 933 megtekintés

( uid_6201 v | 2023. 03. 18., szo – 09:16 )

Szerkesztve: 2023. 03. 18., szo – 09:17

/var/log/syslog fájlt végignézted? Mikor volt szinkronizáció és milyen eredménnyel?

( NevemTeve | 2023. 03. 18., szo – 12:12 )

Nyomozazilag egy éber scripttel másodpercenként kérdezd le az időt: nohup sh -c 'while sleep 1; do date;hwclock; done'

Jó 5let.

Beraktam screen-be, tolja a log fájlt.

Holnap megnézem, mikor mászik el, de gyanítom nem az időszinkron rontja el a dolgokat, most a CPU C3-as állapota lett a gyanúsított, így kikapcsoltam a BIOS-ban, reggelre meglátjuk.

Ha ez nem, nézem tovább.

Itt van mellettem egy működő, majdnem ugyanilyen gép, azzal próbálom összehasonlítani.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

Eredmény:

2023. márc. 19., vasárnap, 22:59:59 CET
2023-03-19 22:59:58.999404+01:00
2023. márc. 19., vasárnap, 23:00:01 CET
2023-03-27 00:00:00.999550+02:00
2023. márc. 12., vasárnap, 23:00:03 CET
2023-03-19 23:00:02.999342+01:00
2023. márc. 12., vasárnap, 23:00:05 CET
2023-03-19 23:00:05.014927+01:00
2023. márc. 12., vasárnap, 23:00:07 CET
2023-03-19 23:00:06.999301+01:00
 

23:00-kor megkotlik az idő.

A cron egy sima backup szkriptet indít, ami rsync-el másolgat.

 

Ééés... a backup script tosz el vmit...rvaélet

 

#!/bin/bash

backup_dir="/mnt/pve/backup-zfs/zfs_deleted/"
backup_log="/var/log/backup.log"
# Do not replace the following two lines!
actual_date=$(date "+%Y_%m_%d")
last_week=$(date -s 'last week' "+%Y_%m_%d")
# Do not replace the following two lines!

rm -r $backup_dir$last_week
rsync -avzrb --delete --backup --backup-dir=$backup_dir$actual_date --recursive --times /zfs_storage/ /mnt/pve/backup-zfs/zfs_storage/ 2> /var/log/backup.log

 

A last_week változó hibádzott, érdekes, hogy a fenti megoldás eddig működött, most ez kell:

 

last_week=$(date --date='last week' "+%Y_%m_%d")

 

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

a -s parameter az eleg regota ottvan: http://web.archive.org/web/20140704065959/https://manpages.ubuntu.com/m…

az hogy "regen mukodott", az csak ugy tunik. lehet regen volt valami ami megakadalyozta hogy ekkorat ugorjon az ido, vagy csak szimplan nem vetted eszre hogy bajban.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A saját backup-ja menti az lxc-ket és a többit.

Ez egy spec. fájlmentéshez kell, mert így kezelhető.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( solt87 | 2023. 03. 18., szo – 12:21 )

Ha a timedactl azt mondja, hogy "NTP Service: active", akkor az kifejezetten a sytemd-timesyncd-t jelenti, nem? Nálam pl. ntpd van (az ntp csomagból), és a timedatectl az "NTP Service"-re azt mondja, hogy "n/a", de ntpq-val látom, hogy működik a szinkronizáció. Csak találgatok, de nem lehet, hogy nálad a systemd-timesyncd és a chrony összeakad valahogy, és esetleg az okozza ezt?

Igen, ez így van. A timedatectl amikor NTP Service-t említ, akkor azon kizárólag a systemd-timmesyncd-t kell érteni, csak azt ismeri. Ettől függetlenül kikapcsolhatod, és feltehetsz más NTP-s szolgáltatást is, nálam is az ntp csomag van fent és azzal szinkronizálokl a timedatectl így nálam is azt írja az NTP Service-re, hogy inactive.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem, ez nem így van:

man timedatectl

       set-ntp [BOOL]
           Takes a boolean argument. Controls whether network time synchronization is active and enabled (if available). If the argument is
           true, this enables and starts the first existing network synchronization service. If the argument is false, then this disables
           and stops the known network synchronization services. The way that the list of services is built is described in systemd-
           timedated.service(8).

systemd-timesyncd will look for files with a ".list" extension in ntp-units.d/ directories. Each file is parsed as a list of unit
       names, one per line. Empty lines and lines with comments ("#") are ignored. Files are read from /usr/lib/systemd/ntp-units.d/ and the
       corresponding directories under /etc/, /run/, /usr/local/lib/. Files in /etc/ override files with the same name in /run/,
       /usr/local/lib/, and /usr/lib/. Files in /run/ override files with the same name under /usr/. Packages should install their
       configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs).

Fedoran pl alapbol active chrony-val.

Ja, értem, hogy ha nincs telepítve systemd-timesync, akkor a következő elérhetőt próbálja kezelni. De pont ez a vicc, hogy timedatectl csak systemd-s disztrókon van, azokon meg jellemzően szinte minden van systemd-timesyncd, úgyhogy elég elméleti, de kösz azért a kiigazítást.

Nálam ezek szerint azért inactive, mert fent van a systemd-tymesyncd, de ki van kapcsolva, mégis jelen van, és ezért nem keres rá a soron következő NTP service-re.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ja, hogy ez egy NTP kliens! Én azt hittem, hogy ez egy cron ütemező fork, de az a cronie, nem chrony. Értem, hogy az elnevezés alapját az a chronos adja, ami a kronométernek is, de ez egy elég benézhető név, ennyire hasonlókat nem kéne teljesen különböző projekteknek adni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( debtamas88 | 2023. 03. 19., v – 12:30 )

Alapból tiltom a "systemd-timesyncd", rakás fos ( timedatectl ).

## /etc/systemd/timesyncd.conf

systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd
systemctl mask systemd-timesyncd

rm -rf /etc/localtime
ln -s /usr/share/zoneinfo/Europe/Budapest /etc/localtime

-> install ntpd/chrony

( NevemTeve | 2023. 03. 19., v – 20:04 )

Off: ha fogadni kellene, arra tennék, hogy ez a probléma létre sem jött volna, ha nincs a systemd.

Hát ja. Nekem egyébként a timesyncd-vel sem lenne nagy bajom, rendesen frissíti az időt, de mégse használom. Ennek az az oka, hogy nem elég konfigurálható, nem eléggé monitorozható. Arch-on az ntp csomagban lévő ntpd/ntpq (ntp.org hivatalos referenciaimplementációja) ezzel szemben unixos felfogású, normális konfigfájllal a /etc-ben, és az ntpdate/ntpq-val elérhető egy csomó kapcsoló, szépen monitorozható, nyomon követhető, hogy milyen peer szerverekről milyen időt szedett, mennyi eltolódás, mekkora jitter, szépen táblázatos statisztikában, látszik mi a fenét csinál, mikor mennyit korrigált, stratum 2-3 közül melyiket használta a peer, melyek a legjobb szerverek, mekkora driftet használ az óra beállításához. Na, ehhez képest a timesyncd holt lebutított, vakon működő valami. Kicsit olyasmi a kettő között a különbség, mint a vim és a notepad/nano között.

“The world runs on Excel spreadsheets.” (Dylan Beattie)