Mint 18.1 - Eine ganze Menge von "Soliciting Pool Server xxx.xxx.xxx.xxx"


11

Ich habe in Syslog nach einem Audioproblem gesucht und sehe verdammt viele der ntp-Daemon-Nachrichten des Soliciting-Poolservers. Ich habe in der Vergangenheit anderes Linux ausgeführt und erinnere mich nie daran, so viele NTP-Protokollnachrichten gesehen zu haben. Liegt dies möglicherweise an einem neuen Netzwerkproblem, ist es bei Mint üblich, gibt es eine Möglichkeit, sie zu beruhigen, wenn es "häufig" ist?

Ich habe seit diesen Tagen die Netzbetreiber- und Router-Hardware gewechselt, damit ich etwas in meinem Netz nicht ausschließe. Ich habe keine Probleme beim Zugriff auf das Internet oder beim Spielen von Online-Spielen usw.


3
Ich bin neu in diesem Bereich, jemand hat die Frage "herabgestuft" - könnten Sie bitte Feedback geben, damit ich weiß, was ich falsch gemacht habe oder warum es sich nicht um eine richtige Frage oder einen richtigen Ort für eine Frage handelt oder?
Varsuuk

2
Ich bin nicht der Downvoter, aber ich sehe ein paar Probleme mit Ihrer Frage, die jemanden abgeschaltet haben könnten: Titel mit einem sehr milden Schimpfwort und nicht sehr beschreibend. Minze (manchmal als Anfänger-Distribution gesehen). Ein 'Problem', das nicht wirklich ein Problem zu sein scheint (welche Probleme verursacht dies, wenn überhaupt?).
Etskinner

1
Ich kann aus dem Titel ersehen, was du meinst. Ich war ein bisschen zu flippig - eigentlich eher "ironisch", wenn man bedenkt, dass ich 52 bin und dieses Wort nie benutze, obwohl ich es heutzutage die ganze Zeit gelesen habe;) (für die Aufzeichnung hätte ich es schlimmer geschrieben als "Eine Hölle von" viel ... "hätte ich nicht getan, wie ich es getan habe. Verzeihen Sie meinem katholischen New Yorker Mangel an Sensibilität; PI wird in Zukunft von einer solchen Verwendung Abstand nehmen (ernsthaft gemeint übrigens - nicht sarkastisch sein.)
Varsuuk

1
Für die Aufzeichnung war der ursprüngliche Titel: Mint 18.1 - Hella viel von "Soliciting Pool Server xxx.xxx.xxx.xxx" - Ich habe es geändert, um nicht zu beleidigen, falls es einige tat.
Varsuuk

@etskinner Und danke für das Feedback, was es gewesen sein könnte. Mein Feedback an den ursprünglichen Downvoter ist ein kurzer Satz über "schlechter Titel / macht seinen Job / etc", der einen großen Beitrag dazu leisten würde, diese Fragen in Zukunft nicht mehr von denen zu hören, die bereit sind zuzuhören. Vielen Dank an alle.
Varsuuk

Antworten:


7

Die Nachrichten bedeuten, dass Ihr NTPD-Server nach mehr Zeitquellen für die Synchronisierung sucht. Es wird erwartet, dass einige davon angezeigt werden, insbesondere nach einer erneuten Verbindung zum Netzwerk nach einem Ausfall oder einem Neustart. Wenn Ihr ntpd und Ihre Netzwerkverbindung jedoch reibungslos funktionieren, sollten Sie nicht mehr als einige pro Tag sehen. Wenn Sie alle paar Minuten mehrere haben, ist dies wahrscheinlich ein Problem.

Stellt Ihr ntpd eine Verbindung zu Peers her und synchronisiert die Zeit erfolgreich? Sie können dies mit überprüfen ntpq. Schauen Sie sich die Liste der Peers in ntpq -c peund die gemeldete Schicht und Reftime in an ntpq -c rv. Eine Schicht von 16 bedeutet "nicht synchronisiert".

Dies:

user@localhost $ ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 de.pool.ntp.org .POOL.          16 p    -   64    0    0.000    0.000   0.002
user@localhost $ ntpq -c rv
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p10@1.3728-o Tue Jun 20 08:08:18 UTC 2017 (1)",
processor="x86_64", system="Linux", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=0.090, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
clock=dde6bdf4.dec8453b  Fri, Dec 22 2017  0:10:44.870, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=4.981, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000

bedeutet, dass Ihr NTP nicht wirklich funktioniert (in diesem Fall, weil ich es gerade gestartet habe), während dies:

user@localhost $ ntpq -c pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 cz.pool.ntp.org .POOL.          16 p    -   64    0    0.000    0.000   0.002
+mail.nettel.cz  195.113.144.201  3 u    4   64  377    5.215   -0.842   0.332
*fedecks.wuji.cz 195.113.144.238  2 u   61   64  377    2.121   -2.005   0.171
-lx.ujf.cas.cz   .GPS.            1 u   62   64  177    2.662   -0.714   0.215
-pyrrha.fi.muni. 195.113.144.238  2 u   63   64  177    7.445   -0.697   0.340
-host-81-200-57- 192.168.3.246    2 u   55   64  177   15.792    0.098   1.160
  cz.inthouse.clo 147.231.2.6      2 u   47   64   17    5.338   -0.266   0.461
user@localhost $ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Sat Jul 29 07:38:14 UTC 2017 (1)",
processor="ppc", system="Linux", leap=00, stratum=2,
precision=-19, rootdelay=2.652, rootdisp=4.409, refid=147.231.100.5,
reftime=dde6be4a.f90912d6  Fri, Dec 22 2017  0:12:10.972,
clock=dde6be4d.12f27b56  Fri, Dec 22 2017  0:12:13.074, peer=10703, tc=6,
mintc=3, offset=-0.387828, frequency=-254.539, sys_jitter=1.572660,
clk_jitter=0.456, clk_wander=0.098

bedeutet, dass Ihr NTP korrekt funktioniert.

Wenn es nicht synchronisiert wird und lange Zeit so bleibt, liegt wahrscheinlich ein Netzwerk- oder Konfigurationsproblem vor. Schauen Sie sich man 5 ntp.confum Hilfe und bei der NTP.org Support - Seite zur Konfiguration für Beispiele. In meinem Fall war der Grund für den endlosen Spam "Pool-Server anfordern" die nopeerAnweisung, die für Pool-Server deaktiviert sein muss.


0

Für mich scheint es nur so, als ob NTP seine Aufgabe erfüllt: Zeitdaten von NTP-Servern anzufordern und diese dann im Syslog zu veröffentlichen. Nichts, über das man sich sorgen sollte.


Vielen Dank, es schien nur eine wirklich ungeheure Menge an Detailprotokollen zu sein, wie "Hey, ich mache meinen Job, nichts Falsches, aber ich werde das nächste Mal überprüfen", alle paar Sekunden bis Minuten voneinander entfernt. Diesmal bin ich zu Mint gewechselt, weil es gut rezensiert wurde und zuletzt Ubuntu hatte, das ich kaum für die Spieleserver meines Kindes und meine Entwicklungs-Repositories verwendet habe. Vorher in den frühen Aughts habe ich Gentoo benutzt und es geliebt (ich habe das erste Mal Stufe 1 wie eine Nuss begonnen, da es nicht wirklich nötig war), aber ich habe es weniger benutzt, als die Zeit knapp wurde und dann jedes Mal, wenn ich es tat - ich ' d zu viel für lange Aufholjagden ausgeben
Varsuuk

Ich habe vergessen, in meinem Spam zu erwähnen ... Ich habe definitiv ein Netzwerkproblem, das ein anderes Problem ist, daher werde ich hier nicht auf Details eingehen (beinhaltet das "Anhalten" von Puttys / Terms / SSH usw., wobei alles, was ich tippe, gepuffert wird, bis der zugrunde liegende Conn wieder hergestellt ist).
Daher

Bitte. Keine Sorge, ich (und die meisten Leute) beurteilen Leute nicht nach Distribution, aber manche Leute tun es. Erstellen Sie am besten eine separate Frage für die anderen Netzwerkprobleme, die Sie sehen. NTP-Protokolle sind zwar ein gutes Symptom, aber es scheint nicht das Problem selbst zu sein.
Etskinner

Wird tun - danke. Ja, ich habe versucht, es nur zu erwähnen, weil es möglicherweise verwandt ist, ABER ich wollte nicht mehr Details angeben, da ich die Frage pro Frage gelesen habe;) Sache (was Sinn macht) - ich hatte einfach keinen Benchmark um die Menge an ntp "Spam" zu messen. Wird sehen, nachdem ich das andere Problem neu verkabelt / getestet habe - wenn gleichzeitig ntp-Spam abfällt. Wird für die Nachwelt aktualisiert;)
Varsuuk
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.