snowy00 Posted March 4 Share Posted March 4 Hi, something happend this night and the Server was not reachable from the local network. After hard reset ""power off" the server starts running properly. This is the last log that received from server: It seems there a lot network issues? By the way at 1:00 it starts a backup of my Docker appdata. (Appdata.Backup) Mar 4 01:01:04 Tower kernel: veth30a58bb: renamed from eth0 Mar 4 01:01:04 Tower kernel: veth00da9cf: renamed from eth0 Mar 4 01:01:06 Tower kernel: vethcd6745b: renamed from eth0 Mar 4 01:01:06 Tower kernel: veth60d5d03: renamed from eth0 Mar 4 01:01:07 Tower kernel: vethbb4d0b3: renamed from eth0 Mar 4 01:01:07 Tower kernel: vethe8a0781: renamed from eth0 Mar 4 01:01:12 Tower kernel: veth628ba8c: renamed from eth0 Mar 4 01:01:13 Tower kernel: veth710ddf1: renamed from eth0 Mar 4 01:01:13 Tower kernel: veth2c67992: renamed from eth0 Mar 4 01:01:14 Tower kernel: veth68e5056: renamed from eth0 Mar 4 01:01:15 Tower kernel: vethb6d5f57: renamed from eth0 Mar 4 01:01:20 Tower kernel: veth0a6f738: renamed from eth0 Mar 4 01:01:26 Tower kernel: veth8afb35f: renamed from eth0 Mar 4 01:01:26 Tower kernel: vethf50f2c4: renamed from eth0 Mar 4 01:01:28 Tower kernel: docker0: port 1(vethd9eada9) entered disabled state Mar 4 01:01:28 Tower kernel: veth7ebc59c: renamed from eth0 Mar 4 01:01:29 Tower kernel: docker0: port 1(vethd9eada9) entered disabled state Mar 4 01:01:29 Tower kernel: device vethd9eada9 left promiscuous mode Mar 4 01:01:29 Tower kernel: docker0: port 1(vethd9eada9) entered disabled state Mar 4 01:01:33 Tower kernel: veth8147789: renamed from eth0 Mar 4 01:01:42 Tower kernel: veth3fb5ef5: renamed from eth0 Mar 4 01:01:44 Tower kernel: vethad0725a: renamed from eth0 Mar 4 01:01:55 Tower kernel: vethd22e44c: renamed from eth0 Mar 4 01:02:10 Tower kernel: vethbe7b9d3: renamed from eth0 Mar 4 01:02:11 Tower kernel: docker0: port 1(veth1c51ad7) entered blocking state Mar 4 01:02:11 Tower kernel: docker0: port 1(veth1c51ad7) entered disabled state Mar 4 01:02:11 Tower kernel: device veth1c51ad7 entered promiscuous mode Mar 4 01:02:14 Tower kernel: eth0: renamed from veth4422939 Mar 4 01:02:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1c51ad7: link becomes ready Mar 4 01:02:14 Tower kernel: docker0: port 1(veth1c51ad7) entered blocking state Mar 4 01:02:14 Tower kernel: docker0: port 1(veth1c51ad7) entered forwarding state Mar 4 01:02:17 Tower kernel: eth0: renamed from veth4d295c1 Mar 4 01:02:17 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:19 Tower kernel: eth0: renamed from vethff47134 Mar 4 01:02:19 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:22 Tower kernel: eth0: renamed from veth6398c38 Mar 4 01:02:22 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:27 Tower kernel: eth0: renamed from veth64e7d71 Mar 4 01:02:27 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:31 Tower kernel: eth0: renamed from veth04c1a21 Mar 4 01:02:31 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:34 Tower kernel: eth0: renamed from veth3d1be86 Mar 4 01:02:34 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:37 Tower kernel: eth0: renamed from veth11676dd Mar 4 01:02:37 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:41 Tower kernel: eth0: renamed from vethd3fa0d0 Mar 4 01:02:41 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:44 Tower kernel: eth0: renamed from veth2fe8a48 Mar 4 01:02:44 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:47 Tower kernel: eth0: renamed from vethf6a7292 Mar 4 01:02:47 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:51 Tower kernel: eth0: renamed from veth09e4ce5 Mar 4 01:02:51 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:54 Tower kernel: eth0: renamed from veth3a4776a Mar 4 01:02:54 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:02:58 Tower kernel: eth0: renamed from veth6ca1441 Mar 4 01:02:58 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:02 Tower kernel: eth0: renamed from veth5a641ad Mar 4 01:03:02 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:05 Tower kernel: eth0: renamed from veth6702d54 Mar 4 01:03:05 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:09 Tower kernel: eth0: renamed from veth45a5fdc Mar 4 01:03:09 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:13 Tower kernel: eth0: renamed from veth8ead0f1 Mar 4 01:03:13 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:17 Tower kernel: eth0: renamed from vethd7596cf Mar 4 01:03:17 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Mar 4 01:03:25 Tower kernel: eth0: renamed from veth81bff7d Mar 4 01:03:25 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth0 Quote Link to comment
itimpi Posted March 4 Share Posted March 4 Those messages are perfectly normal when docker containers start up. If you are getting it frequently then you probably have a container that is crashing - you can check the uptime for your containers to spot a culprit. You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs. The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field. Quote Link to comment
snowy00 Posted March 4 Author Share Posted March 4 Hi itimpi, thanks for the information - pleas find attached the diagnostics from my system. I have already configured the syylog server but not the copy to the flash drive. Maybe you are able to finde some reasons for the crash. Thanks a lot! tower-diagnostics-20240304-1703.zip Quote Link to comment
snowy00 Posted March 6 Author Share Posted March 6 Hi, today the serve crashed again! Could you please have a look... tower-diagnostics-20240306-2038.zip Quote Link to comment
JorgeB Posted March 7 Share Posted March 7 The previous syslog only covers 10 minutes uptime, and there's nothing there relevant, did the server crash after 10 minutes? Quote Link to comment
snowy00 Posted March 7 Author Share Posted March 7 I found this kind of messages in the Log - is that normal? Mar 6 21:34:42 Tower kernel: usb 4-3: reset SuperSpeed USB device number 2 using xhci_hcd Mar 6 21:34:42 Tower kernel: usb 4-3: LPM exit latency is zeroed, disabling LPM. Mar 7 06:44:33 Tower kernel: usb 4-3: reset SuperSpeed USB device number 2 using xhci_hcd Mar 7 06:44:33 Tower kernel: usb 4-3: LPM exit latency is zeroed, disabling LPM. Mar 7 16:01:14 Tower kernel: usb 4-3: reset SuperSpeed USB device number 2 using xhci_hcd Mar 7 16:01:14 Tower kernel: usb 4-3: LPM exit latency is zeroed, disabling LPM. Mar 7 17:29:44 Tower kernel: usb 4-3: reset SuperSpeed USB device number 2 using xhci_hcd Mar 7 17:29:44 Tower kernel: usb 4-3: LPM exit latency is zeroed, disabling LPM. Quote The previous syslog only covers 10 minutes uptime, and there's nothing there relevant, did the server crash after 10 minutes? Nope I started the server after the crash and did the diagnostics - the mirror logfile to flash was activated during the crash. As mentioned by itimpi (and my understanding is) that the logfile should survives a reboot, so I am confused that the log ist not available in this diagnostics. Quote Link to comment
itimpi Posted March 7 Share Posted March 7 3 hours ago, snowy00 said: the mirror logfile to flash was activated during the crash. As mentioned by itimpi (and my understanding is) that the logfile should survives a reboot, so I am confused that the log ist not available in this diagnostics. the problem is that what looks like the mirrored syslog shows the system being shutdown for a reboot - not the server crashing. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.