Abstürze seit debian 10

[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).

[ludwigklr]

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?

Es ist kein virtuelles Interface. Der Server hat 2 Netzwerkkarten und eth1 ist Backup Device
und wird von postfix, news, bind etc. benutzt

Code: Alles auswählen

[   14.815801] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:21:85:fa:8e:44
[   14.831688] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network Connection
[   14.845552] e1000e 0000:02:00.0 eth0: MAC: 2, PHY: 2, PBA No: FFFFFF-0FF
[   15.066622] e1000e 0000:03:00.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:21:85:fa:8e:45
[   15.082477] e1000e 0000:03:00.0 eth1: Intel(R) PRO/1000 Network Connection
[   15.096350] e1000e 0000:03:00.0 eth1: MAC: 2, PHY: 2, PBA No: FFFFFF-0FF
[   25.291266] e1000e 0000:02:00.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
[   25.310527] e1000e 0000:02:00.0 eth0: 10/100 speed: disabling TSO
[   25.322977] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

oder sehe ich das komplett falsch

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

ja das habe ich gestern Nacht gemacht

LG Klaus

[ludwigklr]

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.

Code: Alles auswählen

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller

Die wurden als eth0 mit dhcp konfiguriert und eth1 mit static in /etc/network/interfaces

Ausserdem wurde ein umfangreicher Hardware Check bei Strato angestossen. 3 Std hat der gedauert und brachte kein Ergebnis. Auch wurde crash installiert. Aber bisher keinen
dump gefunden nach den Abstürzen. Im syslog taucht lediglich binäre Daten und dann erfolgt
der reboot ohne Fehlermeldung. Auch auf der seriellen Console ist nichts zum Absturzzeitpunkt
und nachfolgendem reboot zu sehen.

Es ist zum Verzweifeln

Seit gesten Nacht noch kein Absturz

LG Klaus

[TomL]

Ok, also kein virtuelles NIC... allerdings hat der alte Eintrag eth0:1 in der Interfaces darauf hingedeutet. Bitte jetzt mal die folgenden Ausgaben posten, um den jetzt aktuellen Ist-Zustand festzustellen:

Code: Alles auswählen

ip a
ip r s
cat /etc/network/interfaces
systemctl -l | grep -i network
ss -tulpen
journalctl -b -p err

Und auch das hatte ich schon mal erwähnt... syslog ist veraltet... vergiss das, das bekommt m.W. nicht alle Informationen. Du musst mit journalctl nachsehen, ob und wo es Probleme gegeben hat.

BTW, wenn Du Ausgaben eines Befehls postest, bitte oberhalb den Befehl mitposten... sonst fängt man wieder mit Raterei und Glaskugel an, wo diese Ausgaben denn wohl herkommen könnten. Für die Auswertung von Kernel-Messages ist statt 'dmesg'

Code: Alles auswählen

journalctl -b -k

die bessere Wahl.

[fischig]

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...

Völlig logo!

In die interfaces kann man schreiben, was man lustig ist (mal abgesehen von der dann evtl. fälligen Fehlfunktion). Aber wenn ip link show (iproute2-Kommando) eth0 meldet, dann stimmt das erst mal so unabhängig davon, was eine net-tools-Kommando meldete oder ob es überhaupt was meldete (mein Hinweis auf's Gemenge); und es bleibt die offene Frage nach wie vor: Wie kommt das?

Stretch war nur zum Übergang noch auf den alten [Namen] belassen)

von buster aus gesehen gibt es neue, alte und sehr alte Schnittstellennamen. Hier werden die sehr alten verwendet - oder auch nicht, was rauszufinden wäre.

[MSfree]

Code: Alles auswählen

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller

Also nichts exotisches. Ich glaube, dafür ist das Kernelmodul e1000e zuständig.

Die wurden als eth0 mit dhcp konfiguriert und eth1 mit static in /etc/network/interfaces

Wie gesagt, ob eth0 oder mit den neuen Namenskonventionen ist völlig egal. Es spielt auch keine Rolle ob statisch oder per DHCP. Beides führt definitiv nicht zum Absturz.

Ausserdem wurde ein umfangreicher Hardware Check bei Strato angestossen.

Das hatte ich gelesen. Man kann durch testen zwar die Anwesenheit von Fehler finden, du kannst aber nicht die Abwesenheit von Fehler garantieren. Mit anderen Worten, wenn der Hardwaretest eine bestimmte Situation gar nicht testet, dann findet man damit Fehler, die genau durch die nicht getestete Situation entstehen, nicht.

Im syslog taucht lediglich binäre Daten und dann erfolgt der reboot ohne Fehlermeldung.

TomL hatte es schon erwähnt, seit der Umstellung auf systemd spielt das syslog nur noch eine untergeordnete Rolle, und ist in seiner Defaultkonfiguration unvollständig. Du hast zwei Möglichkeiten, entweder du sorgst dafür, daß rsyslog wirklich alles logt, was man durch einen entsprechenden Eintrag in der Datei /etc/systemd/journald.conf erreichen kann. Oder du stellst auf ein persistentes Journal um, so daß die Logs in Zukunft im Binärformat auf der Platte landen, die Meldungen kann man dann mit journalctl aus den Binärdateien klauben. (Beides gleichzeitig, also rsyslogd plus journal ist auch möglich, braucht dann aber doppelten Plattenplatz).

Ich glaube aber nicht, daß man Abstürze mit dem syslog/Journal auf die Spur kommt. Wenn der Kernel abstürzt, ist er auch nicht mehr in der Lage, Meldungen irgendwo hinzuschreiben, ausser auf den Bildschirm (den du bei einem remote Server nicht hast). Zum Schutz des Dateisystems wird es sogar vermieden, noch irgendwo auf Platte zu pinseln, um das Dateisystem nicht zu gefährden. Der Absturzgrund geht also verloren. Aber die Hoffnung stirbt zuletzt.

Liefert

Code: Alles auswählen

dmesg | grep -i firmware

irgendwelche Erkenntnisse?

[TomL]

[Wenn der Kernel abstürzt, ist er auch nicht mehr in der Lage, Meldungen irgendwo hinzuschreiben, ausser auf den Bildschirm (den du bei einem remote Server nicht hast). Zum Schutz des Dateisystems wird es sogar vermieden, noch irgendwo auf Platte zu pinseln, um das Dateisystem nicht zu gefährden. Der Absturzgrund geht also verloren. Aber die Hoffnung stirbt zuletzt.

Erschwerend kommt hinzu, dass wir keine Kenntnis darüber haben, wie kaputt das System bereits ist, ob es überhaupt noch ein Debian ist, oder vielleicht nur noch ein Frankendebian:

Ich habe die Kernel 4.19, 4.9, und 5.5 ausprobiert.

Dabei kam mir das erste mal die Idee, ob es nicht der bessere Weg wäre, ein aktuelles 'Stable' zu installieren.

[ludwigklr]

Liefert

Code: Alles auswählen

dmesg | grep -i firmware

irgendwelche Erkenntnisse?

Code: Alles auswählen

dmesg | grep -i firmware

[   16.443480] radeon 0000:01:05.0: firmware: direct-loading firmware radeon/RS690_cp.bin

LG Klaus

[ludwigklr]

[Wenn der Kernel abstürzt, ist er auch nicht mehr in der Lage, Meldungen irgendwo hinzuschreiben,
ausser auf den Bildschirm (den du bei einem remote Server nicht hast). Zum Schutz des Dateisystems wird es sogar vermieden, noch irgendwo auf Platte zu pinseln, um das Dateisystem nicht zu gefährden. Der Absturzgrund geht also verloren. Aber die Hoffnung stirbt zuletzt.

Erschwerend kommt hinzu, dass wir keine Kenntnis darüber haben, wie kaputt das System bereits ist, ob es überhaupt noch ein Debian ist, oder vielleicht nur noch ein Frankendebian:

Ich habe die Kernel 4.19, 4.9, und 5.5 ausprobiert.

Dabei kam mir das erste mal die Idee, ob es nicht der bessere Weg wäre, ein aktuelles 'Stable' zu installieren.

Hallo,

es ist ein Stable seit dem 8.6.2020 da habe ich mit apt-get dist-upgrade auf debian buster
umgestellt. es wurden 706 Paket aktualisiert. Danach fingen die Abstürze an. Bisher habe ich alle Änderungen nur mit apt-get dist-upgrade durch geführt. Daher sollte es ein Debian sein.

Die nachfolgenden Kernel Änderungen waren Versuche die Abstürze zu stoppen.

LG Klaus

[ludwigklr]

Ok, also kein virtuelles NIC... allerdings hat der alte Eintrag eth0:1 in der Interfaces darauf hingedeutet. Bitte jetzt mal die folgenden Ausgaben posten, um den jetzt aktuellen Ist-Zustand festzustellen:

Code: Alles auswählen

ip a
ip r s
cat /etc/network/interfaces
systemctl -l | grep -i network
ss -tulpen
journalctl -b -p err

meine Ergebnisse

Code: Alles auswählen

ip a

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 45666sec preferred_lft 45666sec
    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
 
----------------------------------------------------------------

ip r s 

default via 85.214.192.1 dev eth0 
85.214.192.1 dev eth0 scope link 
 
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 eth1
iface eth1 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

---------------------------------------------------------------------------------------------

systemctl -l |grep -i network 

● networking.service                                                                       loaded failed failed    Raise network interfaces                                          
  ntp.service                                                                              loaded active running   Network Time Service                                              
  stunnel4.service                                                                         loaded active running   LSB: Start or stop stunnel 4.x (TLS tunnel for network daemons)   
  network-online.target                                                                    loaded active active    Network is Online                                                 
  network.target                                                                           loaded active active    Network                                                           
  nss-lookup.target                                                                        loaded active active    Host and Network Name Lookups                                     

-------------------------------------------------------

ss -tulpen

Netid State  Recv-Q Send-Q                    Local Address:Port   Peer Address:Port                                                                                                                                                            
udp   UNCONN 0      0                        85.214.200.101:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=514)) uid:106 ino:16829 sk:1 <->                    
udp   UNCONN 0      0                        85.214.227.223:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=513)) uid:106 ino:16827 sk:2 <->                    
udp   UNCONN 0      0                             127.0.0.1:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=512)) uid:106 ino:16825 sk:3 <->                    
udp   UNCONN 0      0                        85.214.227.223:123         0.0.0.0:*                                                                                users:(("ntpd",pid=496,fd=19)) ino:19021 sk:4 <->                              
udp   UNCONN 0      0                             127.0.0.1:123         0.0.0.0:*                                                                                users:(("ntpd",pid=496,fd=18)) ino:19019 sk:5 <->                              
udp   UNCONN 0      0                               0.0.0.0:123         0.0.0.0:*                                                                                users:(("ntpd",pid=496,fd=17)) ino:19015 sk:6 <->                              
udp   UNCONN 0      0       [fe80::221:85ff:fefa:8e44]%eth0:123            [::]:*                                                                                users:(("ntpd",pid=496,fd=21)) ino:19025 sk:7 v6only:1 <->                     
udp   UNCONN 0      0                                 [::1]:123            [::]:*                                                                                users:(("ntpd",pid=496,fd=20)) ino:19023 sk:8 v6only:1 <->                     
udp   UNCONN 0      0                                  [::]:123            [::]:*                                                                                users:(("ntpd",pid=496,fd=16)) ino:19012 sk:9 v6only:1 <->                     
tcp   LISTEN 0      128                             0.0.0.0:110         0.0.0.0:*                                                                                users:(("inetd",pid=486,fd=8)) ino:15231 sk:a <->                              
tcp   LISTEN 0      100                             0.0.0.0:465         0.0.0.0:*                                                                                users:(("master",pid=11044,fd=22)) ino:339794 sk:b <->                         
tcp   LISTEN 0      10                       85.214.200.101:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=23)) uid:106 ino:16830 sk:c <->                     
tcp   LISTEN 0      10                       85.214.227.223:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=22)) uid:106 ino:16828 sk:d <->                     
tcp   LISTEN 0      10                            127.0.0.1:53          0.0.0.0:*                                                                                users:(("named",pid=488,fd=21)) uid:106 ino:16826 sk:e <->                     
tcp   LISTEN 0      128                             0.0.0.0:22          0.0.0.0:*                                                                                users:(("sshd",pid=506,fd=3)) ino:16803 sk:f <->                               
tcp   LISTEN 0      25                              0.0.0.0:119         0.0.0.0:*                                                                                users:(("innd",pid=10847,fd=15)) uid:9 ino:339534 sk:10 <->                    
tcp   LISTEN 0      100                             0.0.0.0:25          0.0.0.0:*                                                                                users:(("smtpd",pid=16654,fd=6),("master",pid=11044,fd=13)) ino:339782 sk:11 <->
tcp   LISTEN 0      128                           127.0.0.1:953         0.0.0.0:*                                                                                users:(("named",pid=488,fd=24)) uid:106 ino:16970 sk:12 <->                    
tcp   LISTEN 0      128                             0.0.0.0:540         0.0.0.0:*                                                                                users:(("inetd",pid=486,fd=7)) ino:15229 sk:13 <->                             
tcp   LISTEN 0      128                             0.0.0.0:993         0.0.0.0:*                                                                                users:(("stunnel4",pid=650,fd=8)) ino:18198 sk:14 <->                          
tcp   LISTEN 0      128                             0.0.0.0:995         0.0.0.0:*                                                                                users:(("stunnel4",pid=650,fd=7)) ino:18196 sk:15 <->                          
tcp   LISTEN 0      100                             0.0.0.0:587         0.0.0.0:*                                                                                users:(("master",pid=11044,fd=18)) ino:339788 sk:16 <->                        
tcp   LISTEN 0      511                                   *:80                *:*                                                                                users:(("apache2",pid=18534,fd=4),("apache2",pid=17661,fd=4),("apache2",pid=5922,fd=4),("apache2",pid=5918,fd=4),("apache2",pid=5916,fd=4),("apache2",pid=5909,fd=4),("apache2",pid=1196,fd=4),("apache2",pid=1188,fd=4),("apache2",pid=1187,fd=4),("apache2",pid=1186,fd=4),("apache2",pid=1153,fd=4)) ino:19296 sk:17 v6only:0 <->
tcp   LISTEN 0      100                                [::]:465            [::]:*                                                                                users:(("master",pid=11044,fd=23)) ino:339795 sk:18 v6only:1 <->               
tcp   LISTEN 0      128                                   *:4949              *:*                                                                                users:(("munin-node",pid=769,fd=5)) ino:18353 sk:19 v6only:0 <->               
tcp   LISTEN 0      32                                    *:21                *:*                                                                                users:(("vsftpd",pid=487,fd=3)) ino:16675 sk:1a v6only:0 <->                   
tcp   LISTEN 0      128                                [::]:22             [::]:*                                                                                users:(("sshd",pid=506,fd=4)) ino:16805 sk:1b v6only:1 <->                     
tcp   LISTEN 0      25                                 [::]:119            [::]:*                                                                                users:(("innd",pid=10847,fd=17)) uid:9 ino:339545 sk:1c v6only:1 <->           
tcp   LISTEN 0      100                                [::]:25             [::]:*                                                                                users:(("smtpd",pid=16654,fd=7),("master",pid=11044,fd=14)) ino:339783 sk:1d v6only:1 <->
tcp   LISTEN 0      128                               [::1]:953            [::]:*                                                                                users:(("named",pid=488,fd=25)) uid:106 ino:16971 sk:1e v6only:1 <->           
tcp   LISTEN 0      511                                   *:443               *:*                                                                                users:(("apache2",pid=18534,fd=6),("apache2",pid=17661,fd=6),("apache2",pid=5922,fd=6),("apache2",pid=5918,fd=6),("apache2",pid=5916,fd=6),("apache2",pid=5909,fd=6),("apache2",pid=1196,fd=6),("apache2",pid=1188,fd=6),("apache2",pid=1187,fd=6),("apache2",pid=1186,fd=6),("apache2",pid=1153,fd=6)) ino:19300 sk:1f v6only:0 <->
tcp   LISTEN 0      100                                [::]:587            [::]:*                                                                                users:(("master",pid=11044,fd=19)) ino:339789 sk:20 v6only:1 <->               
--------------------------------------------------------

journalctl -b -p err 
 
-- Logs begin at Tue 2020-06-23 22:47:18 CEST, end at Wed 2020-06-24 12:47:41 CEST. --
Jun 24 01:03:40 server.owl.de kernel: ata1: softreset failed (device not ready)
Jun 24 01:03:40 server.owl.de kernel: ata2: softreset failed (device not ready)
Jun 24 01:04:01 server.owl.de systemd[1]: Failed to start Raise network interfaces.
Jun 24 01:04:02 server.owl.de iscsid[522]: iSCSI daemon with pid=523 started!
Jun 24 01:05:40 server.owl.de stunnel[650]: LOG3[0]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 01:15:40 server.owl.de stunnel[650]: LOG3[1]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 01:18:10 server.owl.de stunnel[650]: LOG3[2]: SSL_accept: Peer suddenly disconnected
Jun 24 01:19:50 server.owl.de stunnel[650]: LOG3[3]: SSL_accept: Peer suddenly disconnected
Jun 24 01:43:08 server.owl.de stunnel[650]: LOG3[4]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 01:43:08 server.owl.de stunnel[650]: LOG3[4]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 01:43:08 server.owl.de stunnel[650]: LOG3[4]: No more addresses to connect
Jun 24 01:48:52 server.owl.de stunnel[650]: LOG3[5]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 01:48:52 server.owl.de stunnel[650]: LOG3[5]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 01:48:52 server.owl.de stunnel[650]: LOG3[5]: No more addresses to connect
Jun 24 01:51:45 server.owl.de stunnel[650]: LOG3[6]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 01:51:45 server.owl.de stunnel[650]: LOG3[6]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 01:51:45 server.owl.de stunnel[650]: LOG3[6]: No more addresses to connect
Jun 24 01:53:33 server.owl.de stunnel[650]: LOG3[7]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 01:53:33 server.owl.de stunnel[650]: LOG3[7]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 01:53:33 server.owl.de stunnel[650]: LOG3[7]: No more addresses to connect
Jun 24 02:15:35 server.owl.de stunnel[650]: LOG3[8]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 02:15:35 server.owl.de stunnel[650]: LOG3[8]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 02:15:35 server.owl.de stunnel[650]: LOG3[8]: No more addresses to connect
Jun 24 02:19:23 server.owl.de stunnel[650]: LOG3[9]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 02:19:23 server.owl.de stunnel[650]: LOG3[9]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 02:19:23 server.owl.de stunnel[650]: LOG3[9]: No more addresses to connect
Jun 24 02:29:58 server.owl.de stunnel[650]: LOG3[10]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 02:29:58 server.owl.de stunnel[650]: LOG3[10]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 02:29:58 server.owl.de stunnel[650]: LOG3[10]: No more addresses to connect
Jun 24 03:21:11 server.owl.de stunnel[650]: LOG3[11]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 03:21:11 server.owl.de stunnel[650]: LOG3[11]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 03:21:11 server.owl.de stunnel[650]: LOG3[11]: No more addresses to connect
Jun 24 03:29:22 server.owl.de stunnel[650]: LOG3[12]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 03:29:22 server.owl.de stunnel[650]: LOG3[12]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 03:29:22 server.owl.de stunnel[650]: LOG3[12]: No more addresses to connect
Jun 24 04:45:02 server.owl.de send-uucp[9403]: ctlinnd returned status 0
Jun 24 06:00:53 server.owl.de stunnel[650]: LOG3[13]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 06:00:53 server.owl.de stunnel[650]: LOG3[13]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 06:00:53 server.owl.de stunnel[650]: LOG3[13]: No more addresses to connect
Jun 24 06:10:38 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#61646: update 'owl.de/IN' denied
Jun 24 06:20:38 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#61974: update 'owl.de/IN' denied
Jun 24 06:25:39 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#56948: update 'owl.de/IN' denied
Jun 24 07:25:39 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#61849: update 'owl.de/IN' denied
Jun 24 07:32:13 server.owl.de stunnel[650]: LOG3[14]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 07:32:13 server.owl.de stunnel[650]: LOG3[14]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 07:32:13 server.owl.de stunnel[650]: LOG3[14]: No more addresses to connect
Jun 24 07:54:24 server.owl.de stunnel[650]: LOG3[15]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:04:20 server.owl.de stunnel[650]: LOG3[16]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:10:36 server.owl.de stunnel[650]: LOG3[17]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:12:22 server.owl.de stunnel[650]: LOG3[18]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 08:12:22 server.owl.de stunnel[650]: LOG3[18]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 08:12:22 server.owl.de stunnel[650]: LOG3[18]: No more addresses to connect
Jun 24 08:14:48 server.owl.de stunnel[650]: LOG3[19]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 08:14:48 server.owl.de stunnel[650]: LOG3[19]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 08:14:48 server.owl.de stunnel[650]: LOG3[19]: No more addresses to connect
Jun 24 08:24:50 server.owl.de stunnel[650]: LOG3[21]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:25:39 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#57069: update 'owl.de/IN' denied
Jun 24 08:31:04 server.owl.de stunnel[650]: LOG3[22]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:34:50 server.owl.de stunnel[650]: LOG3[23]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:40:10 server.owl.de stunnel[650]: LOG3[24]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:40:11 server.owl.de stunnel[650]: LOG3[25]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 08:40:11 server.owl.de stunnel[650]: LOG3[25]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 08:40:11 server.owl.de stunnel[650]: LOG3[25]: No more addresses to connect
Jun 24 08:44:50 server.owl.de stunnel[650]: LOG3[26]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:50:06 server.owl.de stunnel[650]: LOG3[27]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:54:50 server.owl.de stunnel[650]: LOG3[28]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 08:59:36 server.owl.de stunnel[650]: LOG3[29]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:02:15 server.owl.de stunnel[650]: LOG3[30]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 09:02:15 server.owl.de stunnel[650]: LOG3[30]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 09:02:15 server.owl.de stunnel[650]: LOG3[30]: No more addresses to connect
Jun 24 09:04:50 server.owl.de stunnel[650]: LOG3[31]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:09:19 server.owl.de stunnel[650]: LOG3[32]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:12:52 server.owl.de stunnel[650]: LOG3[33]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 09:12:52 server.owl.de stunnel[650]: LOG3[33]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 09:12:52 server.owl.de stunnel[650]: LOG3[33]: No more addresses to connect
Jun 24 09:14:50 server.owl.de stunnel[650]: LOG3[34]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:19:42 server.owl.de stunnel[650]: LOG3[35]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:24:50 server.owl.de stunnel[650]: LOG3[36]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:25:02 server.owl.de stunnel[650]: LOG3[37]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 09:25:02 server.owl.de stunnel[650]: LOG3[37]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 09:25:02 server.owl.de stunnel[650]: LOG3[37]: No more addresses to connect
Jun 24 09:25:39 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#60660: update 'owl.de/IN' denied
Jun 24 09:29:37 server.owl.de stunnel[650]: LOG3[38]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:34:50 server.owl.de stunnel[650]: LOG3[39]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:37:28 server.owl.de stunnel[650]: LOG3[40]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 09:37:28 server.owl.de stunnel[650]: LOG3[40]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 09:37:28 server.owl.de stunnel[650]: LOG3[40]: No more addresses to connect
Jun 24 09:39:46 server.owl.de stunnel[650]: LOG3[41]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:45:20 server.owl.de stunnel[650]: LOG3[42]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:50:13 server.owl.de stunnel[650]: LOG3[43]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 09:55:50 server.owl.de stunnel[650]: LOG3[44]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:00:16 server.owl.de stunnel[650]: LOG3[45]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:05:50 server.owl.de stunnel[650]: LOG3[46]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:08:44 server.owl.de stunnel[650]: LOG3[47]: SSL_accept: Peer suddenly disconnected
Jun 24 10:10:18 server.owl.de stunnel[650]: LOG3[48]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:15:50 server.owl.de stunnel[650]: LOG3[49]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:20:09 server.owl.de stunnel[650]: LOG3[50]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:25:39 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#64059: update 'owl.de/IN' denied
Jun 24 10:25:50 server.owl.de stunnel[650]: LOG3[51]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:30:36 server.owl.de stunnel[650]: LOG3[52]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:34:54 server.owl.de stunnel[650]: LOG3[53]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 10:34:54 server.owl.de stunnel[650]: LOG3[53]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 10:34:54 server.owl.de stunnel[650]: LOG3[53]: No more addresses to connect
Jun 24 10:35:50 server.owl.de stunnel[650]: LOG3[54]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:40:39 server.owl.de stunnel[650]: LOG3[55]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:45:50 server.owl.de stunnel[650]: LOG3[56]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:50:22 server.owl.de stunnel[650]: LOG3[57]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 10:55:50 server.owl.de stunnel[650]: LOG3[58]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:00:12 server.owl.de stunnel[650]: LOG3[59]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:05:41 server.owl.de stunnel[650]: LOG3[60]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 11:05:41 server.owl.de stunnel[650]: LOG3[60]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 11:05:41 server.owl.de stunnel[650]: LOG3[60]: No more addresses to connect
Jun 24 11:05:50 server.owl.de stunnel[650]: LOG3[61]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:09:45 server.owl.de stunnel[650]: LOG3[62]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:15:50 server.owl.de stunnel[650]: LOG3[63]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:20:11 server.owl.de stunnel[650]: LOG3[64]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:22:09 server.owl.de stunnel[650]: LOG3[65]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:25:40 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#62961: update 'owl.de/IN' denied
Jun 24 11:30:04 server.owl.de stunnel[650]: LOG3[67]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:34:56 server.owl.de stunnel[650]: LOG3[68]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:39:43 server.owl.de stunnel[650]: LOG3[70]: SSL_accept: Peer suddenly disconnected
Jun 24 11:40:29 server.owl.de stunnel[650]: LOG3[71]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:43:03 server.owl.de stunnel[650]: LOG3[72]: SSL_accept: Peer suddenly disconnected
Jun 24 11:45:50 server.owl.de stunnel[650]: LOG3[73]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:46:08 server.owl.de stunnel[650]: LOG3[74]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 11:46:08 server.owl.de stunnel[650]: LOG3[74]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 11:46:08 server.owl.de stunnel[650]: LOG3[74]: No more addresses to connect
Jun 24 11:50:26 server.owl.de stunnel[650]: LOG3[75]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 11:55:50 server.owl.de stunnel[650]: LOG3[76]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:00:00 server.owl.de stunnel[650]: LOG3[77]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:05:50 server.owl.de stunnel[650]: LOG3[78]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:09:50 server.owl.de stunnel[650]: LOG3[79]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:09:53 server.owl.de stunnel[650]: LOG3[80]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:15:11 server.owl.de stunnel[650]: LOG3[81]: s_connect: connect ::1:143: Connection refused (111)
Jun 24 12:15:11 server.owl.de stunnel[650]: LOG3[81]: s_connect: connect 127.0.0.1:143: Connection refused (111)
Jun 24 12:15:11 server.owl.de stunnel[650]: LOG3[81]: No more addresses to connect
Jun 24 12:15:50 server.owl.de stunnel[650]: LOG3[82]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:19:29 server.owl.de stunnel[650]: LOG3[83]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:25:40 server.owl.de named[488]: client @0x7f526c0a9fc0 84.118.131.62#56677: update 'owl.de/IN' denied
Jun 24 12:25:50 server.owl.de stunnel[650]: LOG3[84]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:27:07 server.owl.de stunnel[650]: LOG3[85]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:29:15 server.owl.de stunnel[650]: LOG3[86]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:35:50 server.owl.de stunnel[650]: LOG3[87]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:38:46 server.owl.de stunnel[650]: LOG3[88]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:42:46 server.owl.de stunnel[650]: LOG3[89]: s_connect: connect ::1:110: Connection refused (111)
Jun 24 12:45:50 server.owl.de stunnel[650]: LOG3[90]: s_connect: connect ::1:110: Connection refused (111)

BTW, wenn Du Ausgaben eines Befehls postest, bitte oberhalb den Befehl mitposten... sonst fängt man wieder mit Raterei und Glaskugel an, wo diese Ausgaben denn wohl herkommen könnten. Für die Auswertung von Kernel-Messages ist statt 'dmesg'

Code: Alles auswählen

journalctl -b -k

die bessere Wahl.

ich werde mich bemühen.

LG Klaus

[MSfree]

Code: Alles auswählen

dmesg | grep -i firmware
[   16.443480] radeon 0000:01:05.0: firmware: direct-loading firmware radeon/RS690_cp.bin

OK, damit ist klar, daß für deine Netzwerkkarte weder Firmware geladen wird, noch daß Firmware fehlt. Ich glaube, damit ist die Netzwerkkarte und -konfiguration als Absturzgrund, auszuschließen. Ob du die alten Netzwerknamen beläßt oder auf neue umstellst, wird nichts an den Abstürzen ändern.

[MSfree]

Code: Alles auswählen

journalctl -b -p err 
 
-- Logs begin at Tue 2020-06-23 22:47:18 CEST, end at Wed 2020-06-24 12:47:41 CEST. --
...
Jun 24 01:04:02 server.owl.de iscsid[522]: iSCSI daemon with pid=523 started!
Jun 24 01:05:40 server.owl.de stunnel[650]: LOG3[0]: s_connect: connect ::1:110: Connection refused (111)
...

Wozu brauchst du iscsi auf dem Serverr?
Was macht stunnel auf deinem Server?

Beides muß nicht ursächlich für deinen Probleme sein, aber wenn diese Dienste nicht gebraucht werden, muß man sie auch nicht starten. Der Nebeneffekt wäre, daß das Journal dann aussagekräftiger wäre. Im Moment sehe ich nur eine Flut mit dieser Meldungen.

[ludwigklr]

Wozu brauchst du iscsi auf dem Serverr?
Was macht stunnel auf deinem Server?

Beides muß nicht ursächlich für deinen Probleme sein, aber wenn diese Dienste nicht gebraucht werden, muß man sie auch nicht starten. Der Nebeneffekt wäre, daß das Journal dann aussagekräftiger wäre. Im Moment sehe ich nur eine Flut mit dieser Meldungen.

stunnel wird für SSL/TLS Zertifikate von pop3 genutzt

iscsi kenne ich nicht, habe ich deaktiviert

[MSfree]

stunnel wird für SSL/TLS Zertifikate von pop3 genutzt

Das ist aber fehlkonfiguriert, sonst würde der dir das Log nicht so fluten.

[TomL]

Das ist aber fehlkonfiguriert, sonst würde der dir das Log nicht so fluten.

Von der Syntax her deutet der Teiltext im Fehler "connect ::1:143" auf ein IPv6 Problem hin. Ich sehe wohl, dass das Interface eine lokale (LLA), aber keine öffentliche IPv6 (GUA) hat. Offensichtlich bekommt das System keinen Prefix, wobei ich aber nicht weiss, ob das bei Strato bzw. hier in diesem Fall überhaupt Vertragsbestandteil ist. Und wenn nicht, warum ist dann überhaupt IPv6 aktiv?

Ich komme insgesamt auch nicht mit den vergebenen IP-Adressen klar, da sind völlig unterschiedliche Netz konfiguriert, eth0, eth1, Gateway , alles ist hinsichtlich einer gewohnten Netz-Domain 255.255.255.0 unterschiedlich. Das nächste ist, ich weiß auch nicht, was ein Backup-Interface ist.... wozu braucht man sowas? Leider sind die geposteten Ausgaben wieder unvollständig, es fehlt bei den Ausgaben ein großer rechter Teil ... aber was ich bei dem wenigen erkennen kann, lauscht auf dem 2. Interface nur ein DNS-Daemon... sowas läuft bei mir (bis auf dem Pihole, der eben genau dafür da ist) auf keinem einzigen System,auch nicht auf meinem Server.

Und ich verstehe immer noch nicht den Zweck eines zweiten Interfaces auf einem Strato-Server... ich kann mit der Definition Backup hierbei überhaupt nichts anfangen. Außer dem DNS ist ja kein anderer Dienst da, der da explizit lauscht. Ich weiß auch gar nicht, ob das lokale oder globale IPv4-Adressen sind? Sind die -auch wenn sie via DHCP zugewiesen werden- statisch? Für mich würde das alles nur irgendeinen Sinn ergeben, wenn da seitens des Providers eine Subnet-Mask wie 255.255.0.0/16 zugrunde liegen würde, aber das zu glauben fällt mir schwer bei dem allgemein begrenzten IPv4-Pool.

Ich habe hier 'ne Vermutung... und zwar, dass das System schon vor dem Upgrade irgendwie kaputt war, aber dass Änderungen in den Programmen zur Verbesserung der Stabilität bei Buster nun über diese seit jeher vorhandenen Schwächen stolpern. Ob es so ist ...?... keine Ahnung, aber das scheint mir zumindest eine schlüssige Möglichkeit.

Die Baustelle ist mir bei so viel fehlenden Hintergrundinformationen zu schwer... damit bin ich leider überfordert... sorry...

[Tintom]

Das ist aber fehlkonfiguriert, sonst würde der dir das Log nicht so fluten.

Von der Syntax her deutet der Teiltext im Fehler "connect ::1:143" auf ein IPv6 Problem hin. Ich sehe wohl, dass das Interface eine lokale (LLA), aber keine öffentliche IPv6 (GUA) hat. Offensichtlich bekommt das System keinen Prefix, wobei ich aber nicht weiss, ob das bei Strato bzw. hier in diesem Fall überhaupt Vertragsbestandteil ist. Und wenn nicht, warum ist dann überhaupt IPv6 aktiv?

::1 ist IPv6 für localhost, Port 143 ist IMAP.
Nun kann stunnel weder unter IPv4 noch IPv6 auf Port 143 zugreifen, weil schlichtweg dort kein imapd läuft (vorausgesetzt die Angaben sind vollständig), deutet also auf fehlerhafte Konfiguration hin. Wenn das Programm lt. TE eh nur für POP3 verwendet wird sogar nicht mal das. Eher ein Fall von "Funktioniert mit Hintergrundrauschen"

Ich glaube auch nicht, dass die Netzwerkkonfiguration für die Instabilitäten verantwortlich ist. Die Konfiguration ist zwar ungewöhnlich, scheint aber korrekt zu sein.

EDIT: Ich sehe gerade noch vereinzelt Fehlermeldungen im Zusammenhang mit POP (Port 110). Sieht doch so langsam nach Fehlkonfiguration aus.