Serveur Yunohost en retard

Bonjour,

J’essaye d’obtenir de l’aide pour que mon serveur Yunohost soit ponctuel! Depuis plusieurs semaines il retarde et l’heure systeme étant inexacte, je ne peux pas accéder à nextcloud avec l’autentification TOTP, les codes générés n’étant pas concordants avec ceux qui auraient été acceptés par le serveur.
Je tourne en rond depuis quelques jours sans comprendre la raison de ce retard de l’horloge. Le système est Yunohost 4.2.4 VM virtualbox/XygmaNAS (les autres machines virtuelles dont une debian n’ont pas ce problème d’heure)
L’heure retarde dès la mise en route du serveur. Le service fake-hwclock est actif:

● fake-hwclock.service - Restore / save the current clock Loaded: loaded (/lib/systemd/system/fake-hwclock.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2021-05-13 08:43:25 CEST; 1h 18min ago Docs: man:fake-hwclock(8) Process: 233 ExecStart=/sbin/fake-hwclock load $FORCE (code=exited, status=0/SUCCESS) Main PID: 233 (code=exited, status=0/SUCCESS)

mai 13 08:43:25 azerty.com fake-hwclock[233]: jeudi 13 mai 2021, 06:43:25 (UTC+0000)
mai 13 08:43:25 azerty.com systemd[1]: Started Restore / save the current clock.
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Au boot, ntp me semble inactif et j’en ignore d’ailleurs la raison

● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; disabled; vendor preset: ena Drop-In: /etc/systemd/system/ntp.service.d └─ynh-override.conf Active: inactive (dead) Docs: man:ntpd(8)

Le fichier ntp.conf est bien présent

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

#Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

#Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

#You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

#pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
#pick a different set every time it starts up. Please consider joining the
#pool: http://www.pool.ntp.org/join.html
#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst
server 0.fr.pool.ntp.org
server 1.fr.pool.ntp.org
server 2.fr.pool.ntp.org
server 3.fr.pool.ntp.org

#Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
#details. The web page http://support.ntp.org/bin/view/Support/AccessRestrictions
#might also be helpful.

#Note that “restrict” applies to both servers and clients, so a configuration
#that might be intended to block requests from certain clients could also end
#up blocking replies from your own upstream servers.

#By default, exchange time with everybody, but don’t allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

#Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

#Needed for adding pool entries
restrict source notrap nomodify noquery

#Clients from this (example!) subnet have unlimited access, but only if
#cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust

#If you want to provide time to your local subnet, change the next line.
#(Again, the address is an example only.)
#broadcast 192.168.123.255

#If you want to listen to time broadcasts on your local subnet, de-comment the
#next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

Après la mise en route de NTP par, systemctl start ntp, la requete status renvoie

● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; disabled; vendor preset: enabled) Drop-In: /etc/systemd/system/ntp.service.d └─ynh-override.conf Active: active (running) since Thu 2021-05-13 10:20:57 CEST; 5s ago Docs: man:ntpd(8) Process: 1501 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS) Main PID: 1508 (ntpd) Tasks: 2 (limit: 2347) Memory: 1.8M CGroup: /system.slice/ntp.service └─1508 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 114:119

mai 13 10:20:57 azerty.com ntpd[1508]: leapsecond file (‘/usr/share/zoneinfo/leap-seconds.list’): loaded, ex
mai 13 10:20:57 azerty.com ntpd[1508]: Listen and drop on 0 v6wildcard [::]:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listen and drop on 1 v4wildcard 0.0.0.0:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listen normally on 2 lo 127.0.0.1:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listen normally on 3 enp0s3 192.168.1.17:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listen normally on 4 lo [::1]:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listen normally on 5 enp0s3 [fe80::a00:27ff:fe3f:7b56%2]:123
mai 13 10:20:57 azerty.com ntpd[1508]: Listening on routing socket on fd #22 for interface updates
mai 13 10:20:57 azerty.com ntpd[1508]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
mai 13 10:20:57 azerty.com ntpd[1508]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

Si je corrige l’heure avec date -s le retard réapparait systématiquement.

En remerciant les lecteurs de ce long message et encore plus ceux qui répondront.

1 Like

J’ai trouvé un debut de réponse. J’ai installé chrony qui fonctionne parfaitement et synchronise l’heure régulièrement.
Les synchronisations successives corrigeaient des écarts de 10 à 20 secondes toutes les 5 minutes !!
J’ai remarqué que l’utilisation mémoire du serveur XigmaNAS (ZFS) était importante avec 3 machines virtuelles. J’ai donc éteint les deux autres et laissé Yunohost seul en fonctionnement.
Et la miracle, chrony ne fait plus de synchronisation depuis plusieurs heures et l’horloge de yunohost est précise comme une horloge suisse.
Est ce que ce problème d’horloge qui survient sur certaines machines virtuelles sous virtualbox en cas d’occupation mémoire importante est logique voir connu?

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.