Abstürze seit debian 10

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
TomL

Re: Abstürze seit debian 10

Beitrag von TomL » 24.06.2020 12:38:58

MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 12:20:05
[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:
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
23.06.2020 20:32:52
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.

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 24.06.2020 12:58:39

MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 12:20:05

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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 24.06.2020 13:09:47

TomL hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 12:38:58
MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 12:20:05
[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:
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
23.06.2020 20:32:52
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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 24.06.2020 13:22:16

TomL hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 11:54:25
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

Benutzeravatar
MSfree
Beiträge: 10776
Registriert: 25.09.2007 19:59:30

Re: Abstürze seit debian 10

Beitrag von MSfree » 24.06.2020 13:46:58

ludwigklr hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 12:58:39

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.

Benutzeravatar
MSfree
Beiträge: 10776
Registriert: 25.09.2007 19:59:30

Re: Abstürze seit debian 10

Beitrag von MSfree » 24.06.2020 14:00:31

ludwigklr hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 13:22:16

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.

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 24.06.2020 14:40:41

MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:00:31

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

Benutzeravatar
MSfree
Beiträge: 10776
Registriert: 25.09.2007 19:59:30

Re: Abstürze seit debian 10

Beitrag von MSfree » 24.06.2020 14:44:26

ludwigklr hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:40:41
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

Re: Abstürze seit debian 10

Beitrag von TomL » 24.06.2020 17:36:05

MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:44:26
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... :hail:

Benutzeravatar
Tintom
Moderator
Beiträge: 3033
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Abstürze seit debian 10

Beitrag von Tintom » 24.06.2020 19:46:03

TomL hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 17:36:05
MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:44:26
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" :roll:

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.

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 24.06.2020 19:49:56

TomL hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 17:36:05
MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:44:26
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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 25.06.2020 10:56:21

Tintom hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 19:46:03
TomL hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 17:36:05
MSfree hat geschrieben: ↑ zum Beitrag ↑
24.06.2020 14:44:26

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

Re: Abstürze seit debian 10

Beitrag von TomL » 25.06.2020 11:17:57

ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 10:56:21
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"

Benutzeravatar
Tintom
Moderator
Beiträge: 3033
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: Abstürze seit debian 10

Beitrag von Tintom » 25.06.2020 11:48:27

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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 25.06.2020 13:18:26

TomL hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 11:17:57
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 10:56:21
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.

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 25.06.2020 13:24:22

Tintom hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 11:48:27
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

Re: Abstürze seit debian 10

Beitrag von willy4711 » 25.06.2020 13:51:58

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

Re: Abstürze seit debian 10

Beitrag von TomL » 25.06.2020 13:55:28

ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 13:18:26
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.
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 13:18:26
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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 25.06.2020 14:27:16

TomL hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 13:55:28
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 13:18:26
Mit systemd stehe ich zugegener Maße etwas auf dem Kriegsfuß.
ludwigklr hat geschrieben: ↑ zum Beitrag ↑
25.06.2020 13:18:26
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

Benutzeravatar
ludwigklr
Beiträge: 34
Registriert: 23.06.2020 20:17:43

Re: Abstürze seit debian 10

Beitrag von ludwigklr » 09.07.2020 13:19:24

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

Antworten