Edomi in Proxmox LXC container.

[starwarsfan]

Hallo miteinander,

es ist soweit, das ProxMox-Template ist fertig. Siehe hier!

Happy testing.

[saegefisch]

Und für alle, die es dennoch auch mal selber installieren wollen...

Bugfix/Update in der Anleitung, weil mir heute bei Diagrammen auffiel, dass sie in der VM alle 1h Zeitverschiebung hatten. Ursache war, dass edomi zwar in der richtigen Zeitzone CET lief, aber CentOS darunter in UTC. Daher ergänzt: timedatectl set-timezone Europe/Berlin

Achtung: Kein Update im laufenden Betrieb! Wenn man es wie ich nachträglich machen muss: Edomi anhalten, Kommando ausführen per ssh und edomi wieder starten. Danach ist die Zeitverschiebung weg.

[saegefisch]

Ein sporadisches Problem mir Proxmox...

• Proxmox läuft auf dedizierter HW (NUC8i3BEK2, 32GB RAM, 500GB NVMe) seit ein paar Wochen, aufgebaut mit der ISO von Proxmox (6.1-3), also keine Spielereien, keine Experimente. Update-Funktion von Proxmox regelmäßig.
• Derzeit 4 Container (2x edomi, 2x Ubuntu + Docker) auf 1 Knoten
• Auslastung: CPU ~2%, RAM ~ 5%, SSD ~3% | Jeder Container für sich auch problemlos in den definierten Ressourcen, z.B. edomi CPU ~3%, RAM ~12%, SSD~12%

Heute Nacht nun das 3x in diesen Betriebswochen: Proxmox ist nicht mehr sauber erreichbar - ohne einen ersichtliches Ereignis oder Last, weil in den frühen Morgenstunden):

• Web-Oberfläche nicht mehr erreichbar
• Ping geht
• DHCP-Server sagt "declined"
• SSH geht technisch, aber in der Shell geht das meiste nicht: reboot, halt, df, top,...
• Laufwerks-LED zeigt keinerlei Aktivitäten
• Soft-reboot (Power-taste kurz) geht nicht

Nach hartem Reboot (Power-Taste 4s) fährt Proxmox sauber wieder hoch, alles geht wieder.

• Tasks: Das letzte vor dem Reboot ist "Paket-Datenbank aktualisieren: TASK ERROR: command 'apt-get update' failed: exit code 100" - muss aber ~3h vor dem "Problem" gewesen sein, weil ich so lange noch Lebenszeichen von der edomi-VM hatte
• Das Syslog des Knotens beginnt offenbar erst mit dem Reboot - zumindest finde ich keine älteren in der Weboberfläche.

Wenn es läuft, läuft Proxmox wirklich sehr geschmeidig; Einrichtung und Betrieb sind wirklich einfach und angenehm und damit sehr empfehlenswert, Aber eine IT, die sporadisch nicht verlässlich ist, ist... doof...

Hat jemand eine Idee, was die Ursache dieser sporadischen, vermeintlich anlass-losen "Probleme" sein könnte oder hat diese selber schon erlebt?
Wie kann man der Ursache (mit Bordmitteln?) auf den Grund gehen?

[starwarsfan]

Hi,

was macht denn Docker auf der Maschine? Wäre jetzt so aus dem Stehgreif das Einzige, was dort irgendwie nicht so recht dazu passt. "Sicher" ist die Kiste auch nehme ich an? Also so in Richtung Erreichbarkeit, Zugangsdaten etc.?

Mein Cluster läuft seit Monaten resp. seit dem Setup ohne jegliche Probleme 24/7 und auch Work sind mir keine derartigen Probleme bekannt.

[Lonie]

apt-get return code 100 heißt es gab einen Fehler. Leider wird hier nicht genauer unterschieden.

Du könntest in der Konsole auf dem Hosts mal nachsehen was in den apt-logs steht, zu finden unter /var/log/apt/history*
Syslog solltest du über die Shell ebenso unter /var/log/syslog* finden.

[saegefisch]

Produktiver Ausgangspunkt sind in relevanten VLAN einzelne dedizierte Ubuntu-Server mit Docker-Diensten und bisher keine eodmi-VM neben dem dedizierten edomi-1.64-Server

Ziel des Proxmox war ein neuer Server zu sein, der am Router trunked angebunden ist und damit in allen VLAN agieren kann. Ich fahre in dem 1 Knoten eine edomi-VM für PHP-Development und für meine edomi-2.xx-Projekt, in dem ich zur Ablösung meines produktiven 1.64 auf der grünen Wiese neu angefangen habe - es wächst und gedeiht prima - so ohne Altlasten und lesson-lerned von 4 Jahren... Das Projekt wird irgendwann in meinen dedizierten edomi-Server übertragen, wenn ich fertig bin.

Darüber hinaus die Docker-VM, die ich aber noch nicht umgezogen habe vom alten Server - daher dort aktuell nur watchtower und Portainer. Ziel sind 2-3 Docker-VM für die relevanten 2-3 VLAN in Proxmox. Dann kann ich die dedizierten ablösen/abschalten. Ziel: OWFS, NUT, Nextcloud, Webtrees, mehrere Dokuwiki, influxDB, grafana, Mosquitto, TVheadend, pi-hole,...

Fazit: 1x Docker mit watchtower+ Portainer...das hört sich nicht gefährlich an... Liegt hinter 2 FW im "inneren Zirkel", kein Zugang von außen (später per dediziertem RevProxy aus der DMZ wie die anderen Serverdienste auch)

Log ist bis zum Ausfall für meine Augen total unauffällig über Stunden (hat auch niemand drauf gearbeitet) bis 7:21 (rot markiert).

Auszug aus /var/log/syslog

[SIZE=10px]...
Mar 6 07:15:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:15:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:15:43 HAL-proxmox dhclient[648]: DHCPREQUEST for 192.168.xxx.yyy on vmbr0 to 192.168.xxx.1 port 67
Mar 6 07:15:43 HAL-proxmox dhclient[648]: DHCPACK of 192.168.xxx.yyy from 192.168.xxx.1
Mar 6 07:15:43 HAL-proxmox dhclient[648]: bound to 192.168.xxx.yyy -- renewal in 234 seconds.
Mar 6 07:16:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:16:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:16:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:17:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:17:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:17:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:17:01 HAL-proxmox CRON[28835]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Mar 6 07:18:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:18:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:18:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:19:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:19:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:19:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:19:38 HAL-proxmox dhclient[648]: DHCPREQUEST for 192.168.xxx.yyy on vmbr0 to 192.168.xxx.1 port 67
Mar 6 07:19:38 HAL-proxmox dhclient[648]: DHCPACK of 192.168.xxx.yyy from 192.168.xxx.1
Mar 6 07:19:38 HAL-proxmox dhclient[648]: bound to 192.168.xxx.yyy -- renewal in 263 seconds.
Mar 6 07:20:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:20:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
Mar 6 07:20:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.
Mar 6 07:21:00 HAL-proxmox systemd[1]: Starting Proxmox VE replication runner...
Mar 6 07:21:01 HAL-proxmox systemd[1]: pvesr.service: Succeeded.
[COLOR=#c0392b][B]Mar 6 07:21:01 HAL-proxmox systemd[1]: Started Proxmox VE replication runner.[/B][/COLOR]
Mar 6 10:19:58 HAL-proxmox systemd-modules-load[415]: Inserted module 'iscsi_tcp'
Mar 6 10:19:58 HAL-proxmox iscsid: iSCSI logger with pid=428 started![/SIZE]
...

Zum apt-get upgrade: Der ist auch in der kostenlosen Version enthalten oder. Wenn ich den manuell anstoße, kommt meist unauffällig

Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Your System is up-to-date

starting shell
root@HAL-proxmox:/#

In den Wochen hatte ich aber auch schon Pakete zum aktualisieren. Allerdings ist das "nur" das dist-upgrade, nicht das update... In der Shell manuell funktioniert das aber auch unauffällig (Quelle enterprise schlägt erwartet fehl, da keine Subscription, sondern kostenlose Version, richtig?).

root@HAL-proxmox:~# apt-get update
Err:1 https://enterprise.proxmox.com/debian/pve buster InRelease
401 Unauthorized [IP: 212.224.123.70 443]
Hit:2 http://ftp.de.debian.org/debian buster InRelease
Get:3 http://ftp.de.debian.org/debian buster-updates InRelease [49.3 kB]
Get:4 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:4 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:4 http://security-cdn.debian.org buster/updates InRelease [65.4 kB]
Err:4 http://security-cdn.debian.org buster/updates InRelease
Connection failed [IP: 151.101.112.204 80]
Reading package lists... Done
E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/buster/InRelease 401 Unauthorized [IP: 212.224.123.70 443]
E: The repository 'https://enterprise.proxmox.com/debian/pve buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@HAL-proxmox:~#

Es dauert allerdings erstaunlich lange im Vergleich zu meinen Ubuntu-Maschinen. In den Tasks sieht man, dass das tägliche upgrade oft funktioniert ("OK" ~ 50% der Versuche), aber auch regelmäßig (die anderen ~50%) den oben genannten Fehler ("TASK ERROR: command 'apt-get update' failed: exit code 100") wirft. Könnte das ein Indikator für etwas sein? Allerdings liegt der letzte upgrade-Fehler in den Tasks ~4h vor dem "Einfrieren" um 7:21. Das sieht nicht nach direkter Kausalität aus.

Ich sehe keinen Ansatzpunkt für die Analyse dieses sporadischen Verhaltens...bin ratlos...

[starwarsfan]

Hi

Quelle enterprise schlägt erwartet fehl, da keine Subscription, sondern kostenlose Version, richtig?

Das bekommst Du aber einfach in Griff, indem Du /etc/apt/sources.list.d/pve-enterprise.list löschst oder woanders hin verschiebst. Dann gibts keine Update-Probleme mehr.

Ich sehe keinen Ansatzpunkt...bin ratlos...

Ich im Moment auch. Hm, weiter überlegen...

[saegefisch]

HI Yves,
ein wunderbarer Tipp, danke! Das sieht schon besser aus. Nun scheine ich aber ein Thema mit der DNS-Auflösung zu haben. Erstaunlicherweise funktioniert der ping vom ssh auf dem Proxmox auf die selbe Adresse völlig problemlos. In der Proxmox-Shell habe ich mal ein Problem beim ping, mal nicht, aber beim Ugrade schlägt es fehl. Vorhin aber nicht... ARGH! Ich hasse IT-Fehler die fuzzy sind...

root@HAL-proxmox:~# [B]apt-get update[/B]
Err:1 http://ftp.de.debian.org/debian buster InRelease
Temporary failure resolving 'ftp.de.debian.org'
Get:2 http://security-cdn.debian.org buster/updates InRelease [65.4 kB]
Hit:3 http://ftp.de.debian.org/debian buster-updates InRelease
Fetched 22.3 kB in 1min 20s (277 B/s)
Reading package lists... Done
W: Failed to fetch http://ftp.de.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'ftp.de.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
ping: ftp.de.debian.org: Temporary failure in name resolution
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
PING ftp.de.debian.org (141.76.2.4) 56(84) bytes of data.
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=1 ttl=52 time=25.2 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=2 ttl=52 time=22.6 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=3 ttl=52 time=22.2 ms
^C
--- ftp.de.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 22.239/23.372/25.242/1.337 ms
root@HAL-proxmox:~# [B]apt-get update[/B]
Err:1 http://ftp.de.debian.org/debian buster InRelease
Temporary failure resolving 'ftp.de.debian.org'
Hit:2 http://ftp.de.debian.org/debian buster-updates InRelease
Err:3 http://security.debian.org buster/updates InRelease
Temporary failure resolving 'prod.debian.map.fastly.net' Temporary failure resolving 'security.debian.org'
Reading package lists... Done
W: Failed to fetch http://ftp.de.debian.org/debian/dists/buster/InRelease Temporary failure resolving 'ftp.de.debian.org'
W: Failed to fetch http://security.debian.org/dists/buster/updates/InRelease Temporary failure resolving 'prod.debian.map.fastly.net' Temporary failure resolving 'security.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@HAL-proxmox:~#

Nachtrag: Doch gleiches Verhalten per SSH (Alles andere wäre ja auch sehr erstaunlich): Mal geht der ping, mal nicht...

2. Nachtrag: beim 3 Versuch ging es nach Sekunden...

root@HAL-proxmox:~# apt-get update
Hit:1 http://ftp.de.debian.org/debian buster InRelease
Hit:2 http://ftp.de.debian.org/debian buster-updates InRelease
Hit:3 http://security.debian.org buster/updates InRelease
Reading package lists... Done
root@HAL-proxmox:~#

Fazit:

• Ich habe ein (sporadisches) PING-Problem vom Proxmox aus. Erstaunlicherweise von keinem anderen Server aus; von anderen funktioniert der selbe ping zum selben Server verlässlich. Da das der einzige getrunkete ist: Kann ping und trunk manchmal Probleme bereiten?
• Weiterhin scheint schon zeitlich keine Kausalität zwischen diesem Thema und dem eigentlichen Problem des Einfrierens zu geben

[Lonie]

Du hast kein Problem mit ICMP Ping sondern mit DNS welche Server hast du denn in /etc/resolv.conf eingetragen?

[saegefisch]

Hi Marcel, natürlich - in manchen IT-Dingen bin ich nicht immer so scharfkantig, wie ich gerne immer wäre... Daher kein Ping-Thema, sondern natürlich DNS, was ich auch meint, aber halt nicht schrieb... <schäm>.
In /etc/resolv.conf habe ich meine MikroTik stehen. Der hat als primären DNS mein PI-Hole, als sekundären Quad9. Auf dem Weg fragen auch alle anderen Geräte DNS bei mir an. Daher für mich auch so unerklärlich...

domain int
search int
nameserver 192.168.xx.1

Die beiden ersten Zeilen hat Proxmox selber eingetragen - derlei habe ich auf keinem meiner Server.

root@HAL-proxmox:~# [B]dig ftp.de.debian.org[/B]

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> ftp.de.debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.de.debian.org. IN A

;; ANSWER SECTION:
ftp.de.debian.org. 3441 IN A 141.76.2.4

;; Query time: 1 msec
;; SERVER: 192.168.xx.1#53(192.168.xx.1)
;; WHEN: Sat Mar 07 12:29:08 CET 2020
;; MSG SIZE rcvd: 51

root@HAL-proxmox:~#

und unmittelbar danach mal wieder Misserfolg und Erfolg nah beieinander...

root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
ping: ftp.de.debian.org: Temporary failure in name resolution
root@HAL-proxmox:~# [B]ping ftp.de.debian.org[/B]
PING ftp.de.debian.org (141.76.2.4) 56(84) bytes of data.
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=1 ttl=50 time=24.5 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=2 ttl=50 time=23.9 ms
64 bytes from debian.inf.tu-dresden.de (141.76.2.4): icmp_seq=3 ttl=50 time=24.1 ms
^C
--- ftp.de.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 23.919/24.191/24.512/0.275 ms
root@HAL-proxmox:~# ^C

NACHTRAG: Zwei SSH-Terminals nebeinander - 1x mein bestehender Server, 1x Proxmox. Während bei Proxmox es mal geht und meist lange dauert und dann ohne Ergebnis, kann ich im 1. Terminal parallel/gleichzeitig erfolgreich beliebig oft und 100% erfolgreich ausführen:

carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 847 bytes from 192.33.4.12#53(c.root-servers.net) in 7 ms
;; Received 362 bytes from 199.19.57.1#53(d0.org.afilias-nst.org) in 22 ms
;; Received 635 bytes from 194.58.198.32#53(nsp.dnsnode.net) in 24 ms
carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 819 bytes from 192.58.128.30#53(j.root-servers.net) in 20 ms
;; Received 362 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 6 ms
;; Received 296 bytes from 64.68.197.10#53(dns4.easydns.info) in 93 ms
carsten@HAL:~$ dig ftp.de.debian.org +trace | grep 'Received'
;; Received 813 bytes from 192.168.xx.1#53(192.168.30.1) in 0 ms
;; Received 819 bytes from 199.7.83.42#53(l.root-servers.net) in 91 ms
;; Received 362 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 20 ms
;; Received 296 bytes from 192.174.68.100#53(sec1.rcode0.net) in 7 ms
carsten@HAL:~$

2. NACHTRAG: Ich ändere die DNS-Einstellungen des Proxmox-Knotens im Web-Frontend und sehe die Änderung danach prüfbar auch in /ect/resolv.conf. Sie wirken offenbar auch, wenn ich im SSH-Terminal ping/dig teste.

ABER: Nach ein paar Minuten ändert Proxmox meine DNS-Einstellung automatisch zurück auf den Stand vorher. Wirkt da irgend ein Selbstheilungs-Prozess in Proxmox und könnte das ein Indikator für das eigentliche Problem sein?

[starwarsfan]

Hi

In /etc/resolv.conf habe ich meine MikroTik stehen. Der hat als primären DNS mein PI-Hole, als sekundären Quad9. Auf dem Weg fragen auch alle anderen Geräte DNS bei mir an. Daher für mich auch so unerklärlich...

domain int
search int
nameserver 192.168.xx.1

Irgendwie ist das jetzt nicht so recht eindeutig, zumindest für mich. Ich verstehe es aber mal so, als ob der Eintrag in der resolv.conf der MikroTik-Router ist, korrekt? Und da frage ich mich, warum? Ich habe dort direkt meine PiHole-Instanz drin stehen. Was haben denn Deine anderen Geräte vom Router als IP für den DNS bekommen? Die IP vom Router oder die IP vom PiHole? Sprich, geht der DNS-Traffic wirklich erst über den Router?

[saegefisch]

Der MT liefert PI-Hole aus - so wie bei Dir und üblich. Damit muss man sich nie darum kümmern und alle Geräte laufen darüber. Läuft wunderbar seit geraumer Zeit.

Bei Proxmox hatte ich den MT (192.168.xx.1) selber eingetragen (Siehe oben). Aber auch mit PI-Hole als 1. DNS ändert sich nichts oder auch mal direkt 9.9.9.9. Die Symptome bleiben immer gleich.

Und nach ein paar Minuten setzt Proxmox die DNS-Einstellungen automatisch zurück auf meine Einstellungen der Erstinstallation... inkl. dieser beiden Zeilen, die Proxmox selber einträgt.

[starwarsfan]

Hi

Der MT liefert PI-Hole aus - so wie bei Dir und üblich. Damit muss man sich nie darum kümmern und alle Geräte laufen darüber. Läuft wunderbar seit geraumer Zeit.

Das ist schon klar und auch völlig korrekt. Aber bekommt denn Dein ProxMox-Host seine IP auch via DHCP? Wohl eher nicht!? Daher muss i.d.R. auch der DNS explizit konfiguriert werden.

Bei Proxmox hatte ich den MT (192.168.xx.1) selber eingetragen (Siehe oben). Aber auch mit PI-Hole als 1. DNS ändert sich nichts oder auch mal direkt 9.9.9.9. Die Symptome bleiben immer gleich.

Aber das ist m.M.n. falsch. Dort gehört die IP vom DNS hin aber nicht vom Router! Ich weiss nicht, wie sich der MikroTik verhält, wenn da jetzt DNS-Anfragen an ihn kommen...

Und nach ein paar Minuten setzt Proxmox die DNS-Einstellungen automatisch zurück auf meine Einstellungen der Erstinstallation... inkl. dieser beiden Zeilen, die Proxmox selber einträgt.

Das ist klar. Du musst das in der Admin-Oberfläche ändern, zu finden unter "System > DNS".

[saegefisch]

Dem MT sollte es doch ziemlich egal sein, ob die DNS-Anfrage an ihn gestellt wird und er sie an PI-Hole weiter leitet oder der Client direkt bei PI-Hole anfragt. Hm...aber vielleicht hast Du auch schlicht recht... ich weiß es nicht...aber genau deswegen versuche ich ja gerade die damals mal manuell eingestellte DNS-Einstellung auf den PI-Hole umzubiegen - und es fällt immer wieder zurück auf meine initiale Einstellung. Ich vermute, dass dort die Ursache von allem liegt.

Die DNS-Umstellungen habe ich die ganze Zeit schon unter "System -> DNS" gemacht. Habe es auch mal direkt mit /etc/resolv.conf versucht, aber gleiches Ergebnis...

In einem anderem Forum habe ich gelesen, dass es das Verhalten gibt, wenn ein anderer Netzwerk-Manager installiert wird. Ich hätte eigentlich voller Überzeugung gesagt: habe ich nicht, ist alles pur Proxmox! Nach einem Blick in mein Wiki sehe ich aber:

apt install ifupdown2

habe ich damals als einzige zusätzliche Installation gemacht Habe mir damals dazu notiert "für direktes "Apply Configuration"". Möglicherweise kollidieren die beiden? Hat ifupdown2 anderer DNS-Einstellungen als /etc/resolv.conf und wenn ja: wo?

NACHTRAG: Sehe gerade: In der /etc/network/interfaces - habe dort mal DHCP aktiviert und jetzt wird der 1. DNS korrekt auf PI-Hole gesetzt. Yippie. Ändert aber nix daran: ping/dig ist mal erfolgreich, mal dauert es minutenlang, bis dig was "received" hat... Irgendwie scheint Proxmox über PI-Hole unglücklich zu laufen...

Status: ich sehe die Anfragen von Proxmox in PI-Hole als erfolgreich ("OK"). Apt-get update funktioniert im SSH-Terminal. Ping auch - aber manchmal dauert es unfassbar lange - für den ping bis zum timeout. Vielleicht macht DHCP jetzt irgend etwas besser.

Bleibt die ursprüngliche Frage: Das DNS-/Upgrade-Thema war ja Stunden vor dem Einfrieren. Wie kann ich über das SysLog hinaus erforschen, was um 7:21 Proxmox einfrieren ließ?

[ruppsn]

Heute Nacht nun das 3x in diesen Betriebswochen: Proxmox ist nicht mehr sauber erreichbar - ohne einen ersichtliches Ereignis oder Last, weil in den frühen Morgenstunden):

Hi,
hatte ich bei mir auch schon mal, ebenfalls NUC8i3BEK mit einer Kingston SSD, die sogar in der Kompatibilitätsliste von Intel steht. Nachdem ich die gegen eine Samsung ausgetauscht hatte, waren die Probleme weg. Ich muss allerdings dazu sagen, dass das System nie länger als 1 Woche am Stück stabil lief, ist also ein bissl anders gelagert als bei Dir. Ob es Dich weiterbringt, weiß ich aber leider nicht.

VG
Stephan