Perte de l'heure

Support Debian
#1

Sur une Debian 11 avec XFCE, je constate une perte de synchronisation de l’heure.
J’ai une batterie qui n’est plus fonctionnelle, et une utilisation très pépère du système :
dans un bureau virtuel XFCE, un simple tmux et keepassxc
dans un autre bureau une instance de chromium pour les sites comme ce forum qui exigent le havascript
sur tty2 j’ai le client tmux sur la même session que sous XFCE.
sur tty1 j’ai un shell avec les commandes pour voir la charge de la batterie et un simple

systemctl hibernate

pour faire hiberner le système (après avoir fermé chromium) et pour débrancher électriquement le portable.

Au réveil du système je m’aperçoit que l’heure du PC est complètement fausse.

fp2@debpacha:~ $ timedatectl
               Local time: jeu. 2022-04-07 12:11:05 CEST
           Universal time: jeu. 2022-04-07 10:11:05 UTC
                 RTC time: jeu. 2022-04-07 10:11:05
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
fp2@debpacha:~ $ systemctl status time
timers.target     time-set.target   time-sync.target
fp2@debpacha:~ $ systemctl status time-s
time-set.target   time-sync.target
fp2@debpacha:~ $ systemctl status time-sync.target
Display all 454 possibilities? (y or n)
fp2@debpacha:~ $ systemctl status time-sync.target
● time-sync.target - System Time Synchronized
     Loaded: loaded (/lib/systemd/system/time-sync.target; static)
     Active: active since Tue 2022-04-05 22:11:29 CEST; 1 day 14h ago
       Docs: man:systemd.special(7)

avril 05 22:11:29 debpacha systemd[1]: Reached target System Time Synchronized.
fp2@debpacha:~ $

Un peu plus que midi ? La bonne blague.

fp2@debpacha:~ 7s $ date && sudo systemctl restart systemd-timesyncd.service && date
jeu. 07 avril 2022 12:17:20 CEST
jeu. 07 avril 2022 12:17:20 CEST
fp2@debpacha:~ $ date
jeu. 07 avril 2022 16:07:38 CEST
fp2@debpacha:~ $

pas loin de 4 heures de retard ! Merci systemd.
Vérification que la synchro est enclenchée

fp2@debpacha:~ $ systemctl status  -l systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-04-07 12:17:20 CEST; 3h 51min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 130055 (systemd-timesyn)
     Status: "Initial synchronization to time server 172.107.94.157:123 (0.debian.pool.ntp.org)."
      Tasks: 2 (limit: 9360)
     Memory: 1.0M
        CPU: 47ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─130055 /lib/systemd/systemd-timesyncd

avril 07 12:17:20 debpacha systemd[1]: Starting Network Time Synchronization...
avril 07 12:17:20 debpacha systemd[1]: Started Network Time Synchronization.
avril 07 16:07:29 debpacha systemd-timesyncd[130055]: Initial synchronization to time server 172.10>
fp2@debpacha:~ 11s $

Ce n’est pas la première fois que cela arrive. J’ai du mal avec les termes employés.

⏚ 1& fp2@debpacha:~ $ systemctl status | fgrep sync
           │     └─129935 grep -F --color=auto sync
             ├─systemd-timesyncd.service
             │ └─3977 /lib/systemd/systemd-timesyncd
1& fp2@debpacha:~ $
1& fp2@debpacha:~ $ systemctl status | fgrep sync
           │     └─132876 grep -F --color=auto sync
             ├─systemd-timesyncd.service
             │ └─130055 /lib/systemd/systemd-timesyncd
1& fp2@debpacha:~ $

Question : pourquoi relancer systemd-timesyncd.service alors qu’il est supposé redémarrer tout seul ( Restart=always )? J’aurais donc dû faire reload et non restart ? Mais ceci n’explique pas pourquoi j’ai été obligé d’intervenir pour avoir l’heure correcte.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

« Il est souvent trop tôt pour savoir s’il n’est pas trop tard. »
Pierre Dac

« Rien ne sert de penser, faut réfléchir avant. »
Pierre Dac

#2

Si tu veux etre synchronisé il te faut un serveur de temps paramétré sur le système, soit via ton DHCP, soit manuellement.
Il faut regarder du coté de timesyncd et systemd

#3

la pile
la perte de l’heure c’est toujours la pile

#4

oui, mais pour que ce soit récupéré, il faut une synchronisation.
Sauf qu’avec systemd-timesyncd.service, si le DHCp ne fournit pas un serveur NTP, alors il faut le paramétrer à la main dans /etc/systemd/timesync.conf

#5

évidemment, mais si tu la change à la main, elle ne devrait pas bouger
sur windows <=7, la synchro date était un espionnage des pc

#6

Quoi? quel espionnage? sur ce point, vaudrait surement mieux que tu t’abstiennes :slight_smile:

Si tu change sur ton Linux, tu ne la changes pas forcement sur ton Windows. Tout dépend de l’état de ton RTC. La partie matérielle n’est pas forcement modifiée par ta synchronisation logicielle.

#7

ou que tu demandes pourquoi je dis ça.

#8

dans ce message là

#9

de base la synchro date sur windaube se faisait sur un serveur qui enregistrait l’ip.

#10

Comme n’importe quel serveur qui log les accès. Ça n’a rien d’exceptionnel.

#11

personne n’a dit le contraire
c’est même exactement ce que je dis

sauf que les gens ne le savent pas et n’ont pas donné leur autorisation

#12

Encore un coup des gars du réseaux :rofl:

#13

9a n’a rien à voir.
La RGPD c’est sur l’utilisation des données personnelles que tu as pu obtenir, les logs n’en font pas partie si elle ne sont pas individualisées (comme sur un proxy par exemple) sur les services systèmes.