Abstürze seit debian 10

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

[ludwigklr]

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 habe mal nachgeschaut. IPV6 ist Vertragsbestandteil aber nicht aktiviert.
Ich habe deshalb IPV6 abgeschaltet. Erscheint jetzt nicht in der Konfiguration

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?

Der Server hat zwei Interface und somit auch zwei IP Adressen. Schon immer seit 2004.

Der Server lauscht mit all seinen Diensten auf beiden Adressen. Braucht man nicht wirklich
aber macnmal ganz gut.

Code: Alles auswählen

nestat -an |grep ^tcp 

tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN     
tcp        0      0 85.214.200.101:53       0.0.0.0:*               LISTEN     
tcp        0      0 85.214.227.223:53       0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:119             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:540             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN     
tcp        0      0 85.214.200.101:22       5.147.25.172:42098      VERBUNDEN  
tcp        0      0 85.214.227.223:25       109.235.70.138:37232    VERBUNDEN  
tcp        0      0 85.214.227.223:119      130.133.4.4:40431       VERBUNDEN  
tcp        0      1 85.214.227.223:57836    131.234.25.20:119       SYN_SENT   
tcp        0      1 85.214.227.223:56196    82.140.32.144:119       SYN_SENT   
tcp        0     36 85.214.227.223:22       5.147.25.172:54064      VERBUNDEN  

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.

Es sind globale IP Adressen

Wenn man mal ein wenig sucht findet man mit whois durchaus die Adressen
85.214.0.0/16 gehören Strato

ich habe noch weitere Strato Server mit 85.214.201.x und 85.214.152.x Adressen.

LG KLaus

[ludwigklr]

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

Hallo,
Fehler gefunden und eleminiert. In stunnel war imap aktiviert aber
ich haben gar keinen imap Deinst am laufen. Eintrag deaktiviert
Fehlermeldung auf Port 143 gehören der Vergangenheit an.

LG Klaus

[TomL]

Fehler gefunden und eleminiert. In stunnel war imap aktiviert aber
ich haben gar keinen imap Deinst am laufen. Eintrag deaktiviert
Fehlermeldung auf Port 143 gehören der Vergangenheit an.

Das freut mich... pirma .... dann hat das ganze hin und her ja doch was gebracht.... und ich hoffe, Du hast verstanden, wie wichtig die ganzen Rahmeninformationen sind, die das technische Umfeld beschreiben. Ohne den Background des Systemumfelds kann man kaum irgendwelche Fehler diagnostizieren. Ich selber kenne mich mit Netzwerk-Customizing ganz gut aus, war aber mit den Gegebenheiten eines Strato-Servers mit 2 öffentlichen IPv4 einigermaßen überfordert... weil ich damit schlichtweg keine Erfahrungen hatte.

Und den Vorteil der Umstellung von reinen Kernelmeldungen mit dmesg auf das vollständigere Journal hast Du ja nun auch verstanden.... das hat dann letztlich diesen einen Fehler offenbart. Auch wenn das Journal in einem binärformat gespeichert wird, ich habe in den letzten 5 Jahren damit nicht einmal einen Nachteil empfunden. Jetzt bleibt nur zu hoffen, dass es auch Hinweise enthält, die man sich gezielt für die letzte Sitzung ansehen kann, wenn der Server mal wieder crasht. Das geht dann mit

Code: Alles auswählen

# journalctl -b -1
# journalctl -b -1 -p err
# journalctl -b -1 | egrep -i "error|fail"

[Tintom]

Sind die Instabilitäten jetzt auch erledigt? Mir fehlt da der Zusammenhang zwischen fehlkonfiguriertem Programm und Systemneustart

[ludwigklr]

Fehler gefunden und eleminiert. In stunnel war imap aktiviert aber
ich haben gar keinen imap Deinst am laufen. Eintrag deaktiviert
Fehlermeldung auf Port 143 gehören der Vergangenheit an.

Das freut mich... pirma .... dann hat das ganze hin und her ja doch was gebracht.... und ich hoffe, Du hast verstanden, wie wichtig die ganzen Rahmeninformationen sind, die das technische Umfeld beschreiben. Ohne den Background des Systemumfelds kann man kaum irgendwelche Fehler diagnostizieren. Ich selber kenne mich mit Netzwerk-Customizing ganz gut aus, war aber mit den Gegebenheiten eines Strato-Servers mit 2 öffentlichen IPv4 einigermaßen überfordert... weil ich damit schlichtweg keine Erfahrungen hatte.

ich habe seit 1996 Server mit Suse Linux und seit 2004 mit Debian am drehen. Mit systemd
stehe ich zugegener Maße etwas auf dem Kriegsfuß. Wenn man über 20 Jahre mit System V
zurecht kam ist es eine ganz schöne Umstellung.

Und den Vorteil der Umstellung von reinen Kernelmeldungen mit dmesg auf das vollständigere Journal hast Du ja nun auch verstanden.... das hat dann letztlich diesen einen Fehler offenbart. Auch wenn das Journal in einem binärformat gespeichert wird, ich habe in den letzten 5 Jahren damit nicht einmal einen Nachteil empfunden.

Leider hat es bei den letzten Abstürzen nichts gebracht. Es gibt immer noch keine
neuen Erkenntnisse. iscsi, eth0:1 sind eleminiert stunnel korregiert aber die Kiste
stürzt weiter unmotiviert ab. Heute nacht hat er mich 4:50 aus dem Bett geholt.
Mein Watchdog hat angerufen aber keine Erkenntisse aus dem
journalctl -b -1 -p err und soeben um 13:08 der nächste Absturz ebenfalls ohne
Hinweise. Ich überlege alles neu aufzusetzen. Die anderen beiden Server laufen
stabil und mein raspi macht auch keine Probleme mit Debian buster.

[ludwigklr]

Sind die Instabilitäten jetzt auch erledigt? Mir fehlt da der Zusammenhang zwischen fehlkonfiguriertem Programm und Systemneustart

leider nein um 4:50 und 13:08 die letzten beiden Abstürze mit automatischen
reboot keine relevanten Einträge in journalctl -b -1 -p err

LG Klaus der über Neuinstallation nachdenkt

[willy4711]

Vielleicht mal mit

Code: Alles auswählen

journalctl -b -1 -n50

die letzten 50 Zeilen des letzten Boots anzeigen?
Irgendetwas muss das System ja zu Reboot bewegt haben. Vielleicht hast du ja Glück ?

[TomL]

Mit systemd stehe ich zugegener Maße etwas auf dem Kriegsfuß.

Das gibts aber jetzt bereits i m 6. Jahr.... und sysv ist seit 2015 bei Debian obsolet, oder allenfalls zur Nebensächlichkeit verbannt.

Leider hat es bei den letzten Abstürzen nichts gebracht.

Die anderen journalctl-Varianten zeigen auch keine Auffälligkeiten? Was ist, wenn Du einfach nur mit

Code: Alles auswählen

journalctl -b -1

das Log der ganzen vorherigen Sitzung anzeigen lässt und dann am Ende auf Auffälligkeiten prüfst? Ist auch da nichts zu sehen?l

[ludwigklr]

Mit systemd stehe ich zugegener Maße etwas auf dem Kriegsfuß.

Leider hat es bei den letzten Abstürzen nichts gebracht.

Die anderen journalctl-Varianten zeigen auch keine Auffälligkeiten? Was ist, wenn Du einfach nur mit

Code: Alles auswählen

journalctl -b -1

das Log der ganzen vorherigen Sitzung anzeigen lässt und dann am Ende auf Auffälligkeiten prüfst? Ist auch da nichts zu sehen?l

Code: Alles auswählen

journalctl -b -1 |grep "25 13:06"

Jun 25 13:06:03 server.owl.de saslauthd[7049]:                 : auth failure: [user=harry.hops] [service=smtp] [realm=server.owl.de] [mech=sasldb] [reason=Unknown]
Jun 25 13:06:03 server.owl.de postfix/smtpd[7048]: warning: SASL authentication failure: Password verification failed
Jun 25 13:06:03 server.owl.de postfix/smtpd[7048]: warning: unknown[190.196.226.228]: SASL PLAIN authentication failed: authentication failure
Jun 25 13:06:04 server.owl.de postfix/smtpd[7050]: connect from unknown[182.140.146.68]
Jun 25 13:06:04 server.owl.de postfix/smtpd[30962]: NOQUEUE: reject: RCPT from mailpd.shecc.com[180.168.117.213]: 450 4.7.1 <srvq7.shecc.com>: Helo command rejected: Host not found; from=<test02@shecc.com> to=<pierre@starcumulus.owl.de> proto=ESMTP helo=<srvq7.shecc.com>
Jun 25 13:06:04 server.owl.de postfix/smtpd[7048]: lost connection after AUTH from unknown[190.196.226.228]
Jun 25 13:06:04 server.owl.de postfix/smtpd[7048]: disconnect from unknown[190.196.226.228] ehlo=1 auth=0/1 commands=1/2
Jun 25 13:06:04 server.owl.de postfix/smtpd[30962]: disconnect from mailpd.shecc.com[180.168.117.213] ehlo=2 starttls=1 mail=1 rcpt=0/1 quit=1 commands=5/6
Jun 25 13:06:06 server.owl.de postfix/smtpd[7050]: NOQUEUE: reject: RCPT from unknown[182.140.146.68]: 450 4.7.25 Client host rejected: cannot find your hostname, [182.140.146.68]; from=<test@cetcxl.com> to=<kki@royal.owl.de> proto=ESMTP helo=<mail.cetcxl.com>
Jun 25 13:06:06 server.owl.de postfix/smtpd[7050]: disconnect from unknown[182.140.146.68] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8
Jun 25 13:06:09 server.owl.de stunnel[25056]: LOG5[57]: Service [pop3s] accepted connection from 217.226.113.121:59120
Jun 25 13:06:09 server.owl.de stunnel[25056]: LOG5[57]: s_connect: connected 127.0.0.1:110
Jun 25 13:06:09 server.owl.de stunnel[25056]: LOG5[57]: Service [pop3s] connected remote server from 127.0.0.1:57556
Jun 25 13:06:09 server.owl.de solid-pop3d[7052]: connect from 127.0.0.1 (127.0.0.1)
Jun 25 13:06:09 server.owl.de solid-pop3d[7052]: connect from localhost (127.0.0.1)
Jun 25 13:06:09 server.owl.de solid-pop3d[7052]: user ralf authenticated - localhost (127.0.0.1)
Jun 25 13:06:09 server.owl.de stunnel[25056]: LOG5[57]: Connection closed: 927 byte(s) sent to TLS, 55 byte(s) sent to socket
Jun 25 13:06:11 server.owl.de sshd[7056]: Received disconnect from 218.92.0.219 port 56945:11:  [preauth]
Jun 25 13:06:11 server.owl.de sshd[7056]: Disconnected from 218.92.0.219 port 56945 [preauth]

auch davor nichts Auffälliges danach geht es mit dem reboot weiter

Code: Alles auswählen

journalctl -b 

Jun 25 13:08:00 server.owl.de kernel: Linux version 5.6.0-0.bpo.2-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.6.14-2~bpo10+1 (2020-06-09)
Jun 25 13:08:00 server.owl.de kernel: Command line: BOOT_IMAGE=/vmlinuz-5.6.0-0.bpo.2-amd64 root=UUID=6ff14297-5275-446e-ae63-ef59ee1d4828 ro console=tty0 console=ttyS0,57600 crashkernel=384M-:128M

Ich sehe zumindestens nicht Verwerfliches. Alles normales Geschehen

LG Klaus

[ludwigklr]

Hallo,

mein Problem besteht weiterhin in zwei Ausprägungen.

1. unmotivierter reboot
2. eth0 ist nicht erreichbar

Da alle bisherigen Versuchen ins Leer verliefen und eth0 auch
nicht über die serielle Console wieder aktiviert werden konnte habe ich
jetzt ein kleines Shellscript gebaut.

Alle 5 Minuten wird ein ping -c 2 per cron nach extern versucht
wenn der mit Fehler beendet wird erfolgt nach 30 Sekunden ein
erneuter Versuch. Wenn auch der fehlerhaft endet wird der Server
mit /sbin/reboot einfach rebootet. Funktioniert und
hat mir erstmal 2 Nächte beschert ohne durch den server
geweckt zu werden.

Vielen Dank an Alle die mir helfen wollten.

LG Klaus