Abstürze seit debian 10

[ludwigklr]

Hallo,
ich betreibe einen Server bei Strato. Bis zum 10.6. lief der mit
Debian 9 jahrelang ohne Probleme. Dann erfolgte die Umstellung mit
apt-get dist-upgrade auf debian 10 und seit dem ist der Server
36 Mal abgestürzt. Ich habe die Kernel 4.19, 4.9, und 5.5 ausprobiert.
Der server rebootet ohne erkennbaren Grund und tut so als wäre
nichts gewesen. Im syslog sind keine Probleme erkennbar.
Ein mehrstündiger Hardware Check mit Strato Hardware Check
erbrachte keine Probleme.

4 Mal trat der Fehler auf das eth0 auf IPV4 nicht mehr erreichbar
war IPV6 wurde noch angezeigt aber IPV4 fehlte im ifconfig.
Auf dem 2. Interface eth0:0 war der server erreichbar. Auch
hier keine Info im syslog. Nur der Hinweis das eth0 nicht mehr
für ntpd und bind benutzbar ist.

Ich bin am Verzweifeln.

MfG Klaus

[Animefreak79]

Zeigt doch bitte mal zuerst die Ausgabe von

Code: Alles auswählen

cat /etc/network/interfaces

und danach dann bitte mal von

Code: Alles auswählen

ip link show

Ist jetzzt nur mal eine Vermutung, die in Richtung Netzwerkschnittstellenbezeichnung geht.

[ludwigklr]

----------------------------------------------------------
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
#

auto eth0:1
iface eth0:1 inet static
address 85.214.200.101
netmask 255.255.255.255
network 85.214.200.101
broadcast 85.214.200.255
gateway 85.214.192.1

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:21:85:fa:8e:44 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:21:85:fa:8e:45 brd ff:ff:ff:ff:ff:ff
--------------------------------------------------------------------------------------

[ludwigklr]

ifconfig eth0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 85.214.227.223 netmask 255.255.255.255 broadcast 85.214.227.223
inet6 fe80::221:85ff:fefa:8e44 prefixlen 64 scopeid 0x20<link>
ether 00:21:85:fa:8e:44 txqueuelen 1000 (Ethernet)
RX packets 159449 bytes 25754404 (24.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 138287 bytes 39884866 (38.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xfeae0000-feb00000

[Animefreak79]

Er zeigt dir eth0 als primäre Netzwerkschnittstelle an, was irgendwie merkwürdig anmutet, da du ja ein Upgrade auf Buster gemacht hast, wo sich meines Wissens nach die Schnittstellenbezeichnung geändert hat. Was steh denn in dem Verzeichnis /etc/udev/rules.d? Ist dort irgendwo eine Datei mit dem Namen persisten-net.rules o.ä, vorhanden?

[ludwigklr]

cat /etc/udev/rules.d/70-persistant-net.rules vom 11.8.2014
-------------------------------------------------------------------------------
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:85:fa:8e:44", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:05.0/0000:03:00.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:85:fa:8e:45", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
-------------------------------------------------------------------------------

[TomL]

Code: Alles auswählen

cat /etc/network/interfaces
auto eth0:1 
iface eth0:1 inet static
address 85.214.200.101
netmask 255.255.255.255
network 85.214.200.101
broadcast 85.214.200.255
gateway 85.214.192.1

Ich bin total unsicher, weil ich diesen ganzen veralteten Kram wie syslog, ifconfig bereits seit Jahren nicht mehr verwende... ebensowenig wie die /etc/network/interfaces. Aber ich verstehe den Zweck dieses Subinterfaces nicht, weil es ja überhaupt nicht mit einem Netzwerk verbunden ist. Das Subnet 255.255.255.255 macht aus der IP-Adresse, so wie ich das verstehe, nur eine IP ohne Netzwerk. Das Gateway passt auch überhaupt nicht... was ist der Sinn hinter diesem Subinterface? Was soll das tun? Für welchen Zweck wird das gebraucht?

Gibt es nach dem Boot des Systems Fehlermeldungen im Journal?

Code: Alles auswählen

journalctl -b -p err

Gibt es nach einem Absturz und einem Restart des Systems Fehlermeldungen von der vorherigen Session im Journal?

Code: Alles auswählen

journalctl -b -1 -p err

[Tintom]

Bist du sicher, dass diese Konfiguration jemals funktioniert hat?

Neben den Anmerkungen von TomL fällt mir noch auf, dass der Eintrag "network" identisch zu "address" ist, das passt nicht.

EDIT: Wegen der netmask-Adresse ist in diesem Fall address=network korrekt. Konsequenterweise müsste dann aber auch gelten: address=network=broadcast.

[Animefreak79]

Gäbe es keine Möglichkeit, das Netzwerk des betreffenden Gerätes per DHCP zu konfigurieren, anstatt IP, Maske und Gateway manuell einzustellen? Dann bräuchte man nur mit

Code: Alles auswählen

ip link se <schnittstellenbezeichnung> up

und

Code: Alles auswählen

dhclient <schnittstellenbezeichnung>

den Kram einzurichten, was eigentlich auch funktionieren sollte.

Ich bin total unsicher, weil ich diesen ganzen veralteten Kram wie syslog, ifconfig bereits seit Jahren nicht mehr verwende... ebensowenig wie die /etc/network/interfaces.

Das Problem liegt vermutlich darin, dass sich die Bezeichnung der Netzwerkschnittstellen seit Buster geändert hat. Wenn wir in Erfahrung bringen könnten, wie die genaue Bezeichnung auf diesem System lauten muss, haben wir möglicherweise schon gewonnen.

Code: Alles auswählen

eth0

ist sehr wahrscheinlch nicht korrekt, ich frage mich fast, was denn passieren würde, wenn man in der /etc/network/interfaces die Bezeichnung

Code: Alles auswählen

eth0

einfach durch die neuere Bezeichnung

Code: Alles auswählen

enp2s0

ersetzt und dann das Gewusel einfach über DHCP machen lässt... Allerdings bin ich erst vor kurzem durch einen anderen Vorfall hier im Forum, zu der Feststellung gekommen, dass die Schnittstellenbezeichnung offenbar tatsächlich varieren kann, aber nach welchen Kriterien... Wenn man jetzt irgendwie rausbekommen könnte, welche Bezeichnung udev auf dem betreffenden Gerät vergeben würde... Gesetz des Falles, dass enp2s0 richtig wäre sehe das dann wohl so aus:

Code: Alles auswählen

ip link set enp2s0 up

Code: Alles auswählen

dhclient enp2s0

Aber dann dürfte das Netzwerk nicht statisch konfiguriert sein und die /etc/network/interfaces müsste dann wohl so aussehen:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto enp2s0
iface enp2s0 inet dhcp

[ludwigklr]

Gibt es nach dem Boot des Systems Fehlermeldungen im Journal?

Code: Alles auswählen

journalctl -b -p err

-- Logs begin at Tue 2020-06-23 22:12:28 CEST, end at Tue 2020-06-23 22:55:19 CEST. --
Jun 23 22:19:26 server.owl.de stunnel[665]: LOG3[14]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:21:50 server.owl.de stunnel[665]: LOG3[15]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:21:50 server.owl.de stunnel[665]: LOG3[16]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:29:20 server.owl.de stunnel[665]: LOG3[18]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:32:21 server.owl.de stunnel[665]: LOG3[19]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:34:53 server.owl.de stunnel[665]: LOG3[20]: s_connect: connect ::1:143: Connection refused (111)
Jun 23 22:34:53 server.owl.de stunnel[665]: LOG3[20]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 23 22:34:53 server.owl.de stunnel[665]: LOG3[20]: No more addresses to connect
Jun 23 22:39:13 server.owl.de stunnel[665]: LOG3[21]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:42:21 server.owl.de stunnel[665]: LOG3[22]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:49:40 server.owl.de stunnel[665]: LOG3[23]: s_connect: connect ::1:110: Connection refused (111)
Jun 23 22:52:21 server.owl.de stunnel[665]: LOG3[24]: s_connect: connect ::1:110: Connection refused (111)

Gibt es nach einem Absturz und einem Restart des Systems Fehlermeldungen von der vorherigen Session im Journal?

Code: Alles auswählen

journalctl -b -1 -p err

kein Ergebnis

[TomL]

ich frage mich fast, was denn passieren würde, wenn man in der /etc/network/interfaces die Bezeichnung

Code: Alles auswählen

eth0

einfach durch die neuere Bezeichnung

Code: Alles auswählen

enp2s0

ersetzt und dann das Gewusel einfach über DHCP machen lässt..

So funktioniert das nicht. eth0 ist sowas wie ein symlink auf ein Kerneldevice. Wenn du da eine andere Bezeichnung verwendest, passiert einfach gar nix, weil die neue Bezeichnung nur ne Nullnummer ist, ein Text für nix.
Btw, ich halte auch DHCP für unpassend. Ist doch ein stationärer Server, da kann man die ganze unnötige bloatware und potentielle Störungsquellen doch prima deinstallieren.

[ludwigklr]

Bist du sicher, dass diese Konfiguration jemals funktioniert hat?

Neben den Anmerkungen von TomL fällt mir noch auf, dass der Eintrag "network" identisch zu "address" ist, das passt nicht.

EDIT: Wegen der netmask-Adresse ist in diesem Fall address=network korrekt. Konsequenterweise müsste dann aber auch gelten: address=network=broadcast.

Ja dieser Server läuft seit x Jahren bei Strato und das eth0 wird ja per dhcp
konfiguriert.

[TomL]

Code: Alles auswählen

journalctl -b -1 -p err

kein Ergebnis

Dann das journal persistent einrichten und nach dem nächsten Crash sofort nachsehen.

Habe ich die Antwort für den Sinn und Zweck des Subinterfaces auf meinem Handy übersehen?

[ludwigklr]

Hallo,

ich habe das eth0:1 jetzt umgestellt auf eth1

[Tintom]

Bist du sicher, dass diese Konfiguration jemals funktioniert hat?

Neben den Anmerkungen von TomL fällt mir noch auf, dass der Eintrag "network" identisch zu "address" ist, das passt nicht.

EDIT: Wegen der netmask-Adresse ist in diesem Fall address=network korrekt. Konsequenterweise müsste dann aber auch gelten: address=network=broadcast.

Ja dieser Server läuft seit x Jahren bei Strato und das eth0 wird ja per dhcp
konfiguriert.

Ich meine nicht das eth0 sondern dessen statisches virtuelles Interface. Die Fehlermeldung deutet auf fehlende IPv6-Funktionalität hin. Wie ist denn die Ausgabe von ip -a address?

[ludwigklr]

Ich meine nicht das eth0 sondern dessen statisches virtuelles Interface. Die Fehlermeldung deutet auf fehlende IPv6-Funktionalität hin. Wie ist denn die Ausgabe von ip -a address?

Guten Morgen,
das etho Interface wird per dhcp eingerichtet

------------------------ ip - a address --------------------
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:21:85:fa:8e:44 brd ff:ff:ff:ff:ff:ff
inet 85.214.227.223/32 brd 85.214.227.223 scope global dynamic eth0
valid_lft 59956sec preferred_lft 59956sec
inet6 fe80::221:85ff:fefa:8e44/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 00:21:85:fa:8e:45 brd ff:ff:ff:ff:ff:ff
inet 85.214.200.101/32 brd 85.214.200.255 scope global eth1
valid_lft forever preferred_lft forever
-------------------------------------------------------------------------
LG Klaus

[fischig]

eth0 ist sowas wie ein symlink auf ein Kerneldevice.

Und wenn

Code: Alles auswählen

ip link show

den Bezeichner verwendet, dann stimmt der auch, denke ich. (Die Meldung ist abgetippt, er hätte besser das Original kopiert und in Code-Tags gesetzt.) Für mich wäre die Frage, warum der Bezeichner stimmt. Die (offenbar nicht erfolgte) defaultmäßige Umbenennung durch udev ist älter als der Wechsel von stretch auf buster. Wenn ich recht erinnere, passierte die von wheezy auf jessie. Ergo hat der TE selbst daran gedreht (was machbar ist). Das sollte er mitteilen.
Kann es sein dass der TE im Gemenge der zu net-tools und iproute2 gehörenden Kommandos nicht mehr durchblickt? Dann wäre vielleicht zunächst mal dahingehend Klarheit zu verschaffen.

[ludwigklr]

Hallo,

den Server betreibe ich seit 2004 als Hobby und nicht als Profi durchgehend mit Debian.

[fischig]

den Server betreibe ich seit 2004 als Hobby und nicht als Profi durchgehend mit Debian.

Das mag so sein, und ich wäre wahrscheinlich so ziemlich der letzte, der daran etwas rummäkeln dürfte. Ich wollte nur auf ein paar - in meiner Wahrnehmung - Unklarheiten in deiner Darstellung hinweisen, die zu klären, falls sie denn der Klärung bedürfen, dir vielleicht weiterhelfen könnten.

Wenn meine Wahrnehmung falsch/irrelevant ist: vergiss' sie einfach.

[ludwigklr]

den Server betreibe ich seit 2004 als Hobby und nicht als Profi durchgehend mit Debian.

Das mag so sein, und ich wäre wahrscheinlich so ziemlich der letzte, der daran etwas rummäkeln dürfte. Ich wollte nur auf ein paar - in meiner Wahrnehmung - Unklarheiten in deiner Darstellung hinweisen, die zu klären, falls sie denn der Klärung bedürfen, dir vielleicht weiterhelfen könnten.

Hallo,

ok, das ist mein erster Auftriff in diesem Forum und jetzt weiß ich auch was

Code: Alles auswählen

bedeutet.
Die Daten die ich eingeben hatte wurden mit drag und drop vom Original benutzt. Demnächst dann mit code

LG Klaus

[ingo2]

So, ich habe mal bei mir nachgeschaut, da ich auf dem Laptop auch das Problem mit den alten Interface-Namen hatte und habe dazu folgendes notiert:

Die Netzwerk-Interfaces sollten laut Release Notes in Buster auf die neuen Namen
umgestellt werden (Stretch war nur zum Übergang noch auf den alten belassen), s.
https://www.debian.org/releases/stable/ ... on.de.html#
Kapitel 5.1.5.

Umstellung ist mit o.g. Anleitung simpel:

Die alten Namen ermitteln:
echo /sys/class/net/[ew]*
-> /sys/class/net/eth0 /sys/class/net/wlan0

Die neuen namen ermitteln:
udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
-> ID_NET_NAME_PATH=enp0s25

udevadm test-builtin net_id /sys/class/net/wlan0 2>/dev/null
-> ID_NET_NAME_PATH=wlp3s0

Alle relevanten Vorkommnisse in Konfigurationsdateien ermitteln:
# rgrep -w eth0 /etc
-> /etc/laptop-mode/conf.d/ethernet.conf:ETHERNET_DEVICES="eth0"
-> /etc/sysctl.d/10-ipv6-privacy.conf:net.ipv6.conf.eth0.use_tempaddr = 2
-> /etc/udev/rules.d/70-persistent-net.rules
# rgrep -w wlan0 /etc
-> /etc/udev/rules.d/70-persistent-net.rules

Zur Umstellung die 2 Zeilen der Namenszuweisung in
/etc/udev/rules.d/70-persistent-net.rules kommentiert (#)
Kann man alternativ auch löschen.

Initramfs neu bauen:
update-initramfs -u

Reboot

Das hilft vielleicht,
Gruß Ingo

[TomL]

eth0 ist sowas wie ein symlink auf ein Kerneldevice.

Und wenn

Code: Alles auswählen

ip link show

den Bezeichner verwendet, dann stimmt der auch, denke ich.

Ja, richtig, genau das habe ich ja als hier konstanter Sachverhalt genau so festgestellt. Nur funktioniert das eben nicht, wie in #Post angemerkt, einfach enps20 in die 'interfaces' einzutragen... weil es eben ein solches Interface resp. den Symlink dafür nicht gibt.

ich habe das eth0:1 jetzt umgestellt auf eth1

Ich frage jetzt zum dritten Mal.... wofür brauchst Du dieses subinterface? Du musst doch für solche Aktionen wie das Umbennenen des Namens eine sachliche, technische Begründung haben, ebenso wie über die Aufgabe, den Zweck dieses Interfaces. Leider beantwortest Du die Fragen nicht.... kann es daran liegen, dass Du gar keine Kenntnis darüber hast, wofür das gut ist und wie und wodurch das überhaupt verwendet wird? Hast Du mal probiert, ob etwas nicht mehr funktioniert, wenn Du dieses virtuelle Interface komplett entfernst?

Hast Du das Journal auf 'persitent' umgestellt, um nach dem nächsten Crash nach Unstimmigkeiten im Log suchen zu können?

[TomL]

Das hilft vielleicht,

Wobei? Die symbolische Bezeichnung eines Interfaces ist eigentlich keine Problemquelle. Entweder es heisst so, wie es der Kernel bezeichnet, oder es wird im Zuge des systemd-Konzeptes "Predictable Interfacenames" auf einen Firmware-, Topologie- oder Einbauortsabhängigen Namen gesymlinkt, oder es wird wie früher via udev umbenannt. Ist dieser Name einmal vergeben, ist die notwendige Eindeutigkeit gegeben und man kann ihn überall konfliktfrei verwenden. Automatisch passierende Änderungen gibts im Release-Zyklus nicht. Ich würde daran überhaupt nicht rumschrauben, zumal ja hier beim Problem die Bezeichnung 'eth0' wirklich oldschool ist und immer funktioniert.

[MSfree]

Wobei? Die symbolische Bezeichnung eines Interfaces ist eigentlich keine Problemquelle.

Richtig, und die Benennung der Netzwerkschnittstellen ist mit Sicherheit nicht die Ursache für die Abstürze.

Der wahre Grund für die Abstürze ist also bisher nichtmal näherungsweise gefunden. Statt dessen hat man sich an eth0, eth0.0, enp2s0 etc. abgearbeitet.

Die Frage ist doch, ob der Rechner überhaupt abstürzt, oder ob sich nur die Netzwerkschnittstelle verabschiedet, weil die einen Hardwaredefekt hat oder weil ihr eventuell nur Firmware fehlt.

Also, was ist das für Hardware verbaut? Mit lspci sollte man da einen ersten Eindruck bekommen können.

[ingo2]

Das hilft vielleicht,

Wobei? Die symbolische Bezeichnung eines Interfaces ist eigentlich keine Problemquelle. Entweder es heisst so, wie es der Kernel bezeichnet, oder es wird im Zuge des systemd-Konzeptes "Predictable Interfacenames" auf einen Firmware-, Topologie- oder Einbauortsabhängigen Namen gesymlinkt, oder es wird wie früher via udev umbenannt. Ist dieser Name einmal vergeben, ist die notwendige Eindeutigkeit gegeben und man kann ihn überall konfliktfrei verwenden. Automatisch passierende Änderungen gibts im Release-Zyklus nicht. Ich würde daran überhaupt nicht rumschrauben, zumal ja hier beim Problem die Bezeichnung 'eth0' wirklich oldschool ist und immer funktioniert.

Ich zitiere mal aus o.g. Ling, Absatz 5.1.6:

If your system was upgraded from an earlier release, and still uses the old-style network interface names that were deprecated with stretch (such as eth0 or wlan0), you should be aware that the mechanism of defining their names via /etc/udev/rules.d/70-persistent-net.rules is officially not supported by udev in buster (while it may still work in some cases). To avoid the danger of your machine losing networking after the upgrade to buster, it is recommended that you migrate in advance to the new naming scheme (usually meaning names like enp0s1 or wlp2s5, which incorporate PCI bus- and slot-numbers). Take care to update any interface names hard-coded in configuration for firewalls, ifupdown, and so on.

The alternative is to switch to a supported mechanism for enforcing the old naming scheme, such as a systemd .link file (see systemd.link(5)). The net.ifnames=0 kernel commandline option might also work for systems with only one network interface (of a given type).