openntpd läuft nicht mehr

[ObiTobi]

Hallo,

vielleicht hat jemand eine Idee. Openntpd startet plötzlich nicht mehr auf meinem Server. Für gute Ideen wäre ich sehr Dankbar - gibt es Alternativen zu dem Paket? mit apt-cache habe ich nicht wirklich was anderes gefunden.
Ach ja Bullseye mit letzen security Updates.

Code: Alles auswählen

journalctl -u openntpd.service
-- Journal begins at Thu 2021-09-16 16:13:09 CEST, ends at Sat 2021-09-18 10:33:32 CEST. --
Sep 16 16:18:18 xenserver01 systemd[1]: Starting OpenNTPd Network Time Protocol...
Sep 16 16:18:19 xenserver01 ntpd[2929]: configuration OK
Sep 16 16:18:19 xenserver01 systemd[1]: Started OpenNTPd Network Time Protocol.
Sep 16 16:18:19 xenserver01 ntpd[2931]: Terminating
Sep 16 16:18:19 xenserver01 systemd[1]: openntpd.service: Succeeded.
Sep 18 10:03:39 xenserver01 systemd[1]: Starting OpenNTPd Network Time Protocol...
Sep 18 10:03:39 xenserver01 ntpd[17802]: configuration OK
Sep 18 10:03:39 xenserver01 systemd[1]: Started OpenNTPd Network Time Protocol.
Sep 18 10:03:39 xenserver01 ntpd[17804]: Terminating
Sep 18 10:03:39 xenserver01 systemd[1]: openntpd.service: Succeeded.

Ein "strace /usr/sbin/ntpd -f /etc/openntpd/ntpd.conf" bringt mich auch nicht weiter.

Code: Alles auswählen

execve("/usr/sbin/ntpd", ["/usr/sbin/ntpd", "-f", "/etc/openntpd/ntpd.conf"], 0x7ffe7b19ad80 /* 23 vars */) = 0
brk(NULL)                               = 0x55f0c26cc000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=40759, ...}) = 0
mmap(NULL, 40759, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f57cf7cf000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\362\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1321344, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f57cf7cd000
mmap(NULL, 1323280, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f57cf689000
mmap(0x7f57cf698000, 630784, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f57cf698000
mmap(0x7f57cf732000, 626688, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa9000) = 0x7f57cf732000
mmap(0x7f57cf7cb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141000) = 0x7f57cf7cb000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@n\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1839792, ...}) = 0
mmap(NULL, 1852680, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f57cf4c4000
mprotect(0x7f57cf4e9000, 1662976, PROT_NONE) = 0
mmap(0x7f57cf4e9000, 1355776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f57cf4e9000
mmap(0x7f57cf634000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x170000) = 0x7f57cf634000
mmap(0x7f57cf67f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ba000) = 0x7f57cf67f000
mmap(0x7f57cf685000, 13576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f57cf685000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f57cf4c1000
arch_prctl(ARCH_SET_FS, 0x7f57cf4c1740) = 0
mprotect(0x7f57cf67f000, 12288, PROT_READ) = 0
mprotect(0x7f57cf7cb000, 4096, PROT_READ) = 0
mprotect(0x55f0c09c2000, 4096, PROT_READ) = 0
mprotect(0x7f57cf803000, 4096, PROT_READ) = 0
munmap(0x7f57cf7cf000, 40759)           = 0
brk(NULL)                               = 0x55f0c26cc000
brk(0x55f0c26ed000)                     = 0x55f0c26ed000
openat(AT_FDCWD, "/etc/localtime", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 2326
lseek(3, -1467, SEEK_CUR)               = 859
read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\t\0\0\0\t\0\0\0\0"..., 4096) = 1467
close(3)                                = 0
openat(AT_FDCWD, "/etc/openntpd/ntpd.conf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=850, ...}) = 0
read(3, "# $OpenBSD: ntpd.conf,v 1.14 201"..., 4096) = 850
read(3, "", 4096)                       = 0
close(3)                                = 0
geteuid()                               = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
close(3)                                = 0
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=505, ...}) = 0
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 505
read(3, "", 4096)                       = 0
close(3)                                = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=40759, ...}) = 0
mmap(NULL, 40759, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f57cf7cf000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=51696, ...}) = 0
mmap(NULL, 79672, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f57cf4ad000
mmap(0x7f57cf4b0000, 28672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f57cf4b0000
mmap(0x7f57cf4b7000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f57cf4b7000
mmap(0x7f57cf4b9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7f57cf4b9000
mmap(0x7f57cf4bb000, 22328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f57cf4bb000
close(3)                                = 0
mprotect(0x7f57cf4b9000, 4096, PROT_READ) = 0
munmap(0x7f57cf7cf000, 40759)           = 0
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
lseek(3, 0, SEEK_CUR)                   = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=1583, ...}) = 0
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1583
close(3)                                = 0
setpriority(PRIO_PROCESS, 0, -20)       = 0
clock_adjtime(CLOCK_REALTIME, {modes=ADJ_OFFSET_SINGLESHOT, offset=0, freq=140181, maxerror=16000000, esterror=16000000, status=STA_UNSYNC, constant=2, precision=1, tolerance=32768000, time={tv_sec=1631954012, tv_usec=602258}, tick=10000, ppsfreq=0, jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0, errcnt=0, stbcnt=0, tai=0}) = 5 (TIME_ERROR)
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2326, ...}) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f57cf4c1a10) = 19274
exit_group(0)                           = ?
+++ exited with 0 +++

[bluestar]

Hallo,

vielleicht hat jemand eine Idee. Openntpd startet plötzlich nicht mehr auf meinem Server.

Ein paar mehr Infos zu deinem Server wären hilfreich.

Code: Alles auswählen

clock_adjtime(CLOCK_REALTIME, {modes=ADJ_OFFSET_SINGLESHOT, offset=0, freq=140181, maxerror=16000000, esterror=16000000, status=STA_UNSYNC, constant=2, precision=1, tolerance=32768000, time={tv_sec=1631954012, tv_usec=602258}, tick=10000, ppsfreq=0, jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0, errcnt=0, stbcnt=0, tai=0}) = 5 (TIME_ERROR)

TIME_ERROR lässt eigentlich auf einen zu großen Jitter zwischen deiner Server und der Echt-Zeit schließen, du könntest mal folgendes probieren:

Code: Alles auswählen

/usr/sbin/ntpd -s -f /etc/openntpd/ntpd.conf -d

[ObiTobi]

Ein paar mehr Infos zu deinem Server wären hilfreich.

Nicht mehr nötig. Es läuft wieder - aber was hättest Du denn gerne für Infos?

/usr/sbin/ntpd -s -f /etc/openntpd/ntpd.conf -d

Damit konnte ich das Problem zumindest lokalisieren.
Erklärung habe ich aber keine - bei dem von Dir genannten Befehl kam als Fehler dass es ein Verzeichnis /var/run/openntpd vermisst wird. Warum so etwas bei meinem strace nicht zu sehen war verstehe ich nicht. Warum das Verzeichnis nicht beim Start erstellt wird noch weniger. Ich habe 3 weitere Linux (Bullseye) Maschinen wo das Verzeichnis eben beim starten des Dienstes erstellt wird. Aus der Maschine wo ich das Problem hatte ist es nicht der Fall. Ich muss das Verzeichnis manuell erstellen.
Für mich ist es ein nicht zu Ende gedachtes Paket oder Fehlerhaftes Daemon. Der Dienst schreibt zumindest bei Debian alles in /var/lib/openntpdrun bzw. db. Wofür das /var/run/openntpd gut sein soll - obwohl da nichts geschrieben wird, weiß wohl nur der Packetierer oder Entwickler

Aber vielen Dank für die hilfreiche Antwort - ohne hätte ich vermutlich noch sehr lange nach der Fehlerursache gesucht

[tijuca]

Es ist hilfreich wenn man sich mal mit dem FHS (File Hirachie System) auseinandersetzt. Dort ist beschrieben warum die Ordnerstruktur eben genau so ist wie man diese vorfindet. Zum Beispiel für /var.

https://refspecs.linuxfoundation.org/FH ... 03s15.html

[ObiTobi]

Es ist hilfreich wenn man sich mal mit dem FHS (File Hirachie System) auseinandersetzt.

Hast Du auch gelesen was ich geschrieben hatte? Entweder nicht, nicht verstanden was ich geschrieben habe oder ich habe Deine Antwort nicht verstanden.

Nach meinem Kenntnisstand ist alles unter /var/run nach einem Reboot weg und muss so fern notwendig vom Dienst oder sonstigen Services erstellt werden.
Nach meinem Verständnis "meckern" über ein fehlendes Verzeichnis in /var/run Struktur ist fehl am Platz. Und das aus 2 Gründen - Punkt 1 steht oben, der Diesen selbst muss sich drum kümmern. Punkt 2 - wofür ein Verzeichnis anmeckern, wenn es nicht genutzt wird, weil woanders geschrieben wird?

Wenn ich auf dem Holzweg bin - klär mich gerne auf. Ich stelle auch nicht die Grundsätzliche Struktur in Frage, sondern hier im speziellen das Verhalten von dem openntpd Paket/ Dienst. In den nächsten Tagen wenn ich etwas mehr Zeit zum Suchen habe, werde ich untersuchen wer das besagte Verzeichnis auf anderen Kisten erstellt.

[bluestar]

Nicht mehr nötig. Es läuft wieder - aber was hättest Du denn gerne für Infos?

Die Frage ob es wirklich ein echter physikalischer Server oder nur so ein gemieteter vServer-Kram ist.

Warum das Verzeichnis nicht beim Start erstellt wird noch weniger.

Also durch den Eintrag "RuntimeDirectory=openntpd" in der Service-Unit (/lib/systemd/system/openntpd.service) Abschnitt [Service] wird Systemd angewiesen das Verzeichnis vor dem Start des Dienstes anzulegen.

[ObiTobi]

Die Frage ob es wirklich ein echter physikalischer Server oder nur so ein gemieteter vServer-Kram ist.

Physik @Home

Also durch den Eintrag "RuntimeDirectory=openntpd" in der Service-Unit (/lib/systemd/system/openntpd.service) Abschnitt [Service] wird Systemd angewiesen das Verzeichnis vor dem Start des Dienstes anzulegen.

Das wird aber nicht gemacht. Ich habe jetzt aber ein Verdacht warum - muss es nur die Tage verifizieren.
Auf dem Server habe ich den Dienst deaktiviert, da ich vorher mit einem Skript was nach dem Booten läuft virtuelle IP's erstelle. Auf einer davon soll eben ntpd laufen. Heißt, so bald die weitere/ virtuelle Schnittstelle da ist, starte ich mit systemctl start openntpd.service den Dienst.
Auf anderen Maschinen die eben virtuell auf der Hardware laufen, startet der Dienst automatisch und erstellt eben das Verzeichnis. Mal probieren was passiert, wenn ich auf einer dieser Kisten den Dienst auch deaktiviere und später manuell starte

[tijuca]

Hast Du auch gelesen was ich geschrieben hatte? Entweder nicht, nicht verstanden was ich geschrieben habe oder ich habe Deine Antwort nicht verstanden.

Nach meinem Kenntnisstand ist alles unter /var/run nach einem Reboot weg und muss so fern notwendig vom Dienst oder sonstigen Services erstellt werden.
Nach meinem Verständnis "meckern" über ein fehlendes Verzeichnis in /var/run Struktur ist fehl am Platz. Und das aus 2 Gründen - Punkt 1 steht oben, der Diesen selbst muss sich drum kümmern. Punkt 2 - wofür ein Verzeichnis anmeckern, wenn es nicht genutzt wird, weil woanders geschrieben wird?

Wenn ich auf dem Holzweg bin - klär mich gerne auf. Ich stelle auch nicht die Grundsätzliche Struktur in Frage, sondern hier im speziellen das Verhalten von dem openntpd Paket/ Dienst. In den nächsten Tagen wenn ich etwas mehr Zeit zum Suchen habe, werde ich untersuchen wer das besagte Verzeichnis auf anderen Kisten erstellt.

Ich habe sehr wohl gelesen was Du geschrieben hast! Folgender Satz lässt mich jedoch vermuten, dass Dir die Funktionsweise und die Benutzung der Verzeichnisse nicht so ganz klar ist.

Der Dienst schreibt zumindest bei Debian alles in /var/lib/openntpdrun bzw. db. Wofür das /var/run/openntpd gut sein soll - obwohl da nichts geschrieben wird, weiß wohl nur der Packetierer oder Entwickler

Dieser NTP-Deamon ist in C geschrieben, wann der nun was in diese Verzeichnisse schreibt müsstest Du Dir im Quellcode anschauen. Nur weil da nichts liegt wenn Du dort mal hinschaust heißt eben noch nicht, dass diese Verzeichnisse überhaupt nicht benutzt werden.
Es ist schon möglich, dass da ein Zielverzeichnis nicht da ist (warum auch immer), im Binärpaket wird kein Verzeichnis /var/run/openntpd oder /run/opennntpd angelegt. Üblicher Weise gehen Programme an der Stelle davon aus, dass die FHS durch das System allgemein erfüllt wird und nur das selbst benötigte Verzeichnis erstellt wird (also opennntpd innerhalb von {/var}/run.
Viele SysV Init Skripte prüfen das einfach und machen halt einfach ein mkdir/chown, gleiches gilt für Service Units an der Stelle. Ist im Prinzip nichts anderes wie FHS zu gewährleisten.

Wenn es Dich besonders stört dann musst Du einen Wishlist Bugreport erstellen. Wird nur nicht schnell bearbeitet werden, das Paket hat an sich nur noch NMU Uploads erhalten seit rund einem Jahr damit es überhaupt mit Bullseye veröffentlicht werden konnte..

[ObiTobi]

Nur weil da nichts liegt wenn Du dort mal hinschaust heißt eben noch nicht, dass diese Verzeichnisse überhaupt nicht benutzt werden.

Ja das hast Du recht, habe ich erst nicht daran gedacht.

Viele SysV Init Skripte prüfen das einfach und machen halt einfach ein mkdir/chown, gleiches gilt für Service Units an der Stelle. Ist im Prinzip nichts anderes wie FHS zu gewährleisten.

Durch den Satz hast Du mich auf eine weitere Idee gebracht und .... in der Tat im /etc/init.d/ liegt auch ein Startscript für openntpd mit u.a

Code: Alles auswählen

[case "$1" in
        start)
                if [ ! -d "/var/run/openntpd" ]; then
                        mkdir -p /var/run/openntpd
                fi

da ich den Dienst über systemctl start openntpd.service starte gilt das nicht und es wird kein Verzeichnis erstellt

Wenn es Dich besonders stört dann musst Du einen Wishlist Bugreport erstellen. Wird nur nicht schnell bearbeitet werden, das Paket hat an sich nur noch NMU Uploads erhalten seit rund einem Jahr damit es überhaupt mit Bullseye veröffentlicht werden konnte..

Nein stören nicht - ich konnte Durch den Befehl von @bluestar überhaupt herausfinden, dass es daran liegt und durch Deine Ausführung habe ich jetzt noch in /etc/init.d nachgeschaut.