[gelöst] Fehlermeldungen Beim Start von ntpdate

[geier22]

Debian Tetsing (xfce und Cinnamon) mit den gleichen Fehler- Meldungen
Vorgeschichte:
Das systemd - Journal wurde bei mir regelmäßig mit einem Haufen Fehlermeldungen vollgeschrieben:

Code: Alles auswählen

ntpd[1237]: error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2)

Das lag (liegt) nach meinen Recherchen wohl daran, dass systemd ntp zu früh gestartet hat.

Da ich an sich gar keinen NTP- Server haben will, da das neine Fritz.Box erledigen soll hab ich erst mal ntp gepurgt und
stattdessen ntpdate installiert. In die /etc/default/ntpdate habe ich folgendes eingetragen:

Code: Alles auswählen

# The settings in this file are used by the program ntpdate-debian, but not
# by the upstream program ntpdate.
# Set to "yes" to take the server list from /etc/ntp.conf, from package ntp,
# so you only have to keep it in one place.
NTPDATE_USE_NTP_CONF=no
# List of NTP servers to use  (Separate multiple servers with spaces.)
# Not used if NTPDATE_USE_NTP_CONF is yes.
NTPSERVERS="fritz.box"
# Additional options to pass to ntpdate
NTPOPTIONS=""

Nun kommen folgende (Fehler)meldungen:

Code: Alles auswählen

journalctl -b |grep ntpdate
Apr 30 10:36:00 sparkyxfce ntpdate[757]: Can't find host fritz.box: Name or service not known (-2)
Apr 30 10:36:00 sparkyxfce ntpdate[757]: no servers can be used, exiting
Apr 30 10:36:12 sparkyxfce ntpdate[1838]: adjust time server fd00::9ec7:a6ff:fe57:f950 offset -0.232867 sec

Fazit: jetzt hab ich zwar die Fehlermeldungen reduziert, aber anscheinend wird auch ntpdate zu früh gestartet
denn der Network Manager ist erst hier fertig:

Code: Alles auswählen

Apr 30 10:36:01 sparkyxfce systemd[1]: Started Network Manager.

Da ich mich nicht so richtig mit den units von systemd auskenne (besser: gar nicht)
vor allem durch das Zusammenwirken von

/etc/systemd/system/network-online.target.wants/networking.service
und
/etc/init.d/network-manager sowie /etc/init.d/networking

überhaupt nicht durchblicke, wäre ich für Tipps sehr dankbar.

[TomL]

Wenn Du auch systemd-networkd anstatt dem alten Networking nutzt, was ich jetzt unbedingt empfehlen kann (und auch würde), würde ich auch ntpdate wieder deinstallieren und den Job stattdessen in Gänze von systemd-timesyncd erledigen lassen. Das ist total easy und funktioniert bestens. Statt großer Beschreibung hier an dieser Stelle schau Dir einfach diese Lösung an....das klappt:
https://wiki.archlinux.de/title/Systemd ... -timesyncd

[guennid]

@toml

Wie arbeitet das Teil (systemd-networkd)? Mir z.B. genügt es, bei Bedarf mal die Zeit von meinem Router zu holen, (also wenn ich mal an einem Rechner eine Abweichung im Minutenbereich feststelle, was nur alle paar Monate mal vorkommt) und so möchte ich das auch haben.

Grüße, Günther

[TomL]

systemd-networkd hat nix mit NTP zu tun, sondern allein mit dem in systemd optimal eingebundenen parallelen Start des Daemons fürs Netzwerk. Das heisst, systemd-networkd öffnet die Interfaces und verbindet das System mit dem Router. Bei mir tuts das mit DHCP, aber Static-IP sind ebenfalls möglich. Das Customizing, Start, Stop, Enable bzw. Disable des Dienstes ist m.E. viel einfacher als über das alte init.d-Script... und vor allem passt es sich eben besser in die neue Welt mit systemd ein. Ich habe alle Systeme umgestellt und bemerkt, dass sich dadurch die Anzahl Kernel-Messages reduziert haben und der Bootprozess um ein Drittel / ein Viertel schnell als zuvor abläuft. Eigentlich läuft damit alles irgendwie besser als zuvor, alles, was mit Netzwerk zu tun hat.... Remote-FS, SSH... sowohl beim Start, als auch beim Shutdown.... irgendwie macht systemd das alles konfliktfrei.

Ich habe mit der Umstellung gewisser Dienste bisher nur gute Erfahrungen gemacht:
networking -> systemd-networkd
ntp -> systemd-timesyncd
rsyslog -> systemd-journald
resolve -> systemd-resolved

Und jeweils den alten Kram habe ich rigoros deinstalliert.

[geier22]

@TomL
Danke für den Tipp ! Sieht wirklich easy aus - werde ich nachher gleich mal Probieren.
Wie oft die Zeit da nun synchronisiert wird, ist mir an sich Schurz
Mich nerven einfach die Fehlermeldungen Bei NTP (den ich zudem ja gar nicht brauche) waren es ja jeweils die ganzen Zeitserver (pool 0 - 3 .debian.pool.ntp.org)
die jeweils das Protokoll voll kritzelten.
Ich hab halt gerne eine "leere" erste Seite in den gnome-logs und das ist der erste wahrscheinlich einfachste Schritt.

[TomL]

Wie oft die Zeit da nun synchronisiert wird, ist mir an sich Schurz

Wenn ich mir nach Stunden die Status-Messages der Unit anschaue, dann denke ich, das ist etwas, über das man sich am allerwenigsten Gedanken machen muss. Der PC ist -habe gerade mal nachgesehen- synchron mit meiner Funk-Uhr. Mehr interessiert mich hier auch nicht.

Code: Alles auswählen

$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since Sa 2016-04-30 10:38:19 CEST; 5h 18min ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 382 (systemd-timesyn)
   Status: "Using Time Server 193.175.73.151:123 (0.de.pool.ntp.org)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─382 /lib/systemd/systemd-timesyncd

Apr 30 11:03:58 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 1024s/-0.013s/0.073s/0.029s/-31ppm
Apr 30 11:21:03 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/+0.026s/0.037s/0.032s/-31ppm (ignored)
Apr 30 11:55:11 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/+0.048s/0.029s/0.038s/-15ppm
Apr 30 12:29:19 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/-0.032s/0.064s/0.039s/-15ppm (ignored)
Apr 30 13:03:27 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/-0.031s/0.030s/0.039s/-25ppm
Apr 30 13:37:36 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/+0.007s/0.023s/0.045s/-23ppm
Apr 30 14:11:44 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/-0.000s/0.025s/0.042s/-23ppm
Apr 30 14:45:52 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/-0.020s/0.080s/0.029s/-27ppm
Apr 30 15:20:00 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/+0.018s/0.044s/0.029s/-23ppm
Apr 30 15:54:09 thomaspc systemd-timesyncd[382]: interval/delta/delay/jitter/drift 2048s/+0.009s/0.026s/0.028s/-20ppm

[geier22]

So - Prima die Fehlermeldungen im Startprotokoll sind erst mal weg.

Code: Alles auswählen

root@sparkyxfce:/home/hans# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Sa 2016-04-30 18:38:39 CEST; 10min ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 13528 (systemd-timesyn)
   Status: "Synchronized to time server 212.59.0.2:123 (0.debian.pool.ntp.org)."
    Tasks: 2 (limit: 512)
   CGroup: /system.slice/systemd-timesyncd.service
           └─13528 /lib/systemd/systemd-timesyncd

Apr 30 18:38:39 sparkyxfce systemd[1]: Starting Network Time Synchronization...
Apr 30 18:38:39 sparkyxfce systemd-timesyncd[13528]: The system is configured to read the RTC time in the local time zone. This mode can not be fully supported. All system time to RTC updates are disabled.
Apr 30 18:38:39 sparkyxfce systemd[1]: Started Network Time Synchronization.
Apr 30 18:38:39 sparkyxfce systemd-timesyncd[13528]: Synchronized to time server 212.59.0.2:123 (0.debian.pool.ntp.org).

Allerdings verstehe ich nicht die zweite Zeile:

The system is configured to read the RTC time in the local time zone. This mode can not be fully supported. All system time to RTC updates are disabled.

Schein ja noch irgendwo ein Haar in der Suppe zu sein
weiter:

Code: Alles auswählen

root@sparkyxfce:/home/hans# timedatectl
      Local time: Sa 2016-04-30 18:57:15 CEST
  Universal time: Sa 2016-04-30 16:57:15 UTC
        RTC time: Sa 2016-04-30 18:57:15
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'. 

Hab ich dann gemacht:

Code: Alles auswählen

root@sparkyxfce:/home/hans# timedatectl set-local-rtc 0

Warnung weg:

Code: Alles auswählen

root@sparkyxfce:/home/hans# timedatectl
      Local time: Sa 2016-04-30 18:59:01 CEST
  Universal time: Sa 2016-04-30 16:59:01 UTC
        RTC time: Sa 2016-04-30 16:59:01
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: no
 RTC in local TZ: no
root@sparkyxfce:/home/hans# 

Bleibt noch die Frage warum:

NTP synchronized: no

[cosmac]

hi,

wahrscheinlich bist du nur zu ungeduldig. Ein seriöser ntpd braucht mindestens ein paar Minuten bis zu "synchronized", bei schlechtem Netzwerk (z.B. DSL) auch deutlich länger.

[mat6937]

Code: Alles auswählen

ntpd[1237]: error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2)

Code: Alles auswählen

NTPSERVERS="fritz.box"

BTW: Wenn Du eine FritzBox hast die im (W)LAN als Zeitserver fungieren kann, dann hättest Du ntpd oder ntpdate so konfigurieren können, dass keine andere (externe) Zeitserver genutzt werden und für die FritzBox deren interne IP-Adresse verwendet wird. Dann gibt es auch keine Probleme mit einer (frühzeitigen) Namensauflösung (... wenn ntpd zu schnell gestartet wird).

Aber der Umstieg auf systemd-timesyncd.service ist m. E. auch ok.

EDIT:

BTW: ntpd muss nicht im (W)LAN als Server fungieren:

Code: Alles auswählen

:~$ rdate -4npu -o 123 192.168.178.43
rdate: Ignoring NTP server with alarm flag set
rdate: Unable to get a reasonable time estimate

[geier22]

so - sowohl in Cinnamon als auch in Xfce eingerichtet (hatte vergessen in der /etc/systemd/timesyncd.conf die eine Zeile auszukommentieren )
Damit scheint das Problemchen gelöst - Danke nochmal an alle

Code: Alles auswählen

hans@sparkyxfce:~$ timedatectl
      Local time: So 2016-05-01 10:45:38 CEST
  Universal time: So 2016-05-01 08:45:38 UTC
        RTC time: So 2016-05-01 08:45:38
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

und

Code: Alles auswählen

hans@sparkyxfce:~$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since So 2016-05-01 12:42:30 CEST; 1h 56min left
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 691 (systemd-timesyn)
   Status: "Synchronized to time server 192.168.0.1:123 (192.168.0.1)."
    Tasks: 2 (limit: 512)
   CGroup: /system.slice/systemd-timesyncd.service
           └─691 /lib/systemd/systemd-timesyncd

Mai 01 12:42:30 sparkyxfce systemd[1]: Starting Network Time Synchronization...
Mai 01 12:42:30 sparkyxfce systemd[1]: Started Network Time Synchronization.
Mai 01 10:43:03 sparkyxfce systemd-timesyncd[691]: Synchronized to time server 192.168.0.1:123 (192.168.0.1).
hans@sparkyxfce:~$ 

[guennid]

Wenn Du auch systemd-networkd [...] nutzt, [...] würde ich auch ntpdate wieder deinstallieren und den Job stattdessen in Gänze von systemd-timesyncd erledigen lassen.

Womit wir wieder bei der Frage wären, ob das alles von einem init-System erledigt werden sollte.

Grüße, Günther

[TomL]

Womit wir wieder bei der Frage wären, ob das alles von einem init-System erledigt werden sollte.

Genau hier besteht m.E. der Gedankenfehler.... das init-System "systemd" hat nur insofern mit dem daemon "systemd-networkd" zu tun, als das beide zu einer optimal zusammenwirkenden Familie von Anwendungen und Programmen gehören, die jeder für sich jeweils für eigene Aufgaben zuständig sind. systemd (init-system) ist die Alternative für sysvinit, systemd-networkd ist die Alternative für /etc/networking, systemd-Journald ist die Alternative für rsyslog, systemd-timesyncd ist die Alternative für ntp, usw., usw..... all diese Anwendungen sind aber nicht das Init-System

Man sieht das auch in meiner Prozessliste... einzelne Prozesse für bestimmte Aufgaben, wo der Prozess nicht (auch) das initsystem ist:

Code: Alles auswählen

ps -aux | grep systemd
root       181  0.0  0.0  37180  5016 ?        Ss   10:20   0:00 /lib/systemd/systemd-journald
root       197  0.0  0.0  41652  3948 ?        Ss   10:20   0:00 /lib/systemd/systemd-udevd
systemd+   385  0.0  0.0 102104  2564 ?        Ssl  10:20   0:00 /lib/systemd/systemd-timesyncd
root       469  0.0  0.0  28268  2888 ?        Ss   10:20   0:00 /lib/systemd/systemd-logind
systemd+   485  0.0  0.0  34380  2856 ?        Ss   10:20   0:00 /lib/systemd/systemd-networkd
systemd+   499  0.0  0.0  25748  2288 ?        Ss   10:20   0:00 /lib/systemd/systemd-resolved
lightdm    684  0.0  0.0  35768  3984 ?        Ss   10:20   0:00 /lib/systemd/systemd --user
thomas     712  0.0  0.0  35776  3876 ?        Ss   10:20   0:00 /lib/systemd/systemd --user
thomas    1774  0.0  0.0  12752  2264 pts/2    S+   15:13   0:00 grep systemd

Das init-System ist der "Starter" und die Diensteverwaltung. Zusätzlich gibts aber in der "systemd-Familie" eben noch haufenweise Anwendungen für jeweils eigene isolierte Aufgaben, die mir mit dem Namenszusatz "systemd" nur signalisieren, dass sie hier optimal integriert sind. Aber alles was irgendwie "systemd" im Namen hat als Init-System zu bezeichnen ist schlichtweg falsch.

Die systemd-Familie (also das Init-System UND alle Systemd-Programme) hat es meines Erachtens geschafft, das über Jahrzehnte gewachsene (imho fast) zufällige Aufeinander-Abgestimmt-Sein vieler Komponenten auf eine gemeinsame Linie zu ziehen und dafür zu sorgen, dass alle Komponenten auf eine gemeinsame Basis blicken und sich an gemeinsame Regeln zu halten. Den Erfolg oder Misserfolg sieht man daran, welche alten Prozesse nicht mit der Parallelisierung klarkommen... etwas, was in moderner EDV m.E. zwingend ist.... das heisst, die Schwächen der alten Prozesse werden offenkundig.

BTW, nicht das das Missverstanden wird.... ich bin kein Fan-Boy von systemd. Ich betrachte das ebenso nüchtern, wie ich Windows, Debian oder andere Linux-Distributionen betrachte. Was systemd aus rein technischer Pespektive angeht, so verschiebt genau diese systemd-Familie meiner Meinung nach das eigentlich total überaltete Linux teilweise auf eine moderne IT-Ebene. sysvinit ist für mich ne zwangsbeatmete Mumie. Systemd war der richtige Schritt. Und es wäre noch einiges mehr an Modernisierungsschritten nötig.

Ob ich das alles so richtig einschätze.... weiss ich nicht... ich tus halt einfach.....und schau dabei ein bisschen auf meine Erfahrungen zurück.

[guennid]

all diese Anwendungen sind aber nicht das Init-System

das wollte ich auch nicht gesagt haben. Aber deine schöne Metapher von der systemd-"Familie" schmeckt mir noch nicht besonders. Man kann das so sehen. Für mich bleibt's zunächst mal ein Konzentrations-Prozess.

Im Übrigen danke ich für die ausführliche und verständliche Darlegung.

[TomL]

Für mich bleibt's zunächst mal ein Konzentrations-Prozess.

Ich vermute und deute das mal eher weniger als Konzentration und dafür etwas mehr als zentrale Regulierung. Ich stelle mir das bei der Parallelisierung so vor, als würde ein ganzer Infanterie-Zug gleichzeitig anfangen zu schießen wenn da nicht einer im Groben die Richtung vorgibt und sagt,ab wann geschossen werden darf, hat man möglicherweise einige unnötige Opfer durch friendly fire. Und mit ähnlicher Notwendigkeit stelle ich mir das bei systemd vor.... einer gibt die Richtung vor und sagt, ab wann geschossen werden darf.... aber ab dann ist jeder Prozess für sich selber verantwortlich und dabei muss jeder Schütze selbst auch auf seinen "Nachbarn" achten, sofern es dazu eine Notwendigkeit (Abhängigkeit) gibt.

Im Gegensatz dazu stellt sysvinit die Schützen einzeln nacheinander hin und erlaubt jedem seinen Schuss, um dann den nächsten Schützen hinzustellen. Warum? Weil die einzelnen Schützen nie was anderes gelernt haben und eher weniger auf abgestimmtes Zusammenwirken achten mussten ... ein Job für eine Aufgabe.... aber so kann man imho heute keine IT-Schlacht mehr gewinnen..... wo wir doch gerade bei Metaphern sind