Emma2
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Hallo.
Ich weiß nicht, ob dies das richtige Unterforum ist; also, lieber Mod, ggf. bitte verschieben - danke! Ich habe einen Virtualisierungshost, auf dem bisher Win 2k12 R2 mit Hyper-V lief, und die Kiste fror "immer mal wieder" ein und tat nix mehr, so etwa alle paar Wochen einmal. Zu Beginn dachte ich, es läge an der Speichertaktung, aber die liegt nun sogar unter dem möglichen Maximum. Danach habe ich vermutet, es sei "wieder mal Windows", was die Probleme machte. Jedenfalls habe ich nun Ubuntu 20.04 "Server" (also keine GUI) drauf, dazu Webmin (sicherheitsmäßig kein Problem, weil nur intern erreichbar) und eben Virtualbox. Alles war prima, aber heute - nach 32 Tagen - ist die Kiste doch stehengeblieben: selbst direkt am Blech tat sich nichts mehr auf der Konsole. (Auf Strg+C hat er noch "^C" angezeigt, aber dann ging gar nichts mehr, allerdings blinkte der Cursorstrich noch.) Nun zu meiner Frage: Kann ich herausfinden, wie und wo es zu dem "Hänger" kam? Ich bin sicher, Ubuntu hat da entsprechende Protokolle, aber so tief bin ich noch lange nicht in meinen Kenntnissen, dass ich die auf Anhieb finden würde und dann noch auswerten könnte. Könnt Ihr mir dabei bitte helfen?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Emma2 schrieb: […] Protokolle
Das Systemlog seit dem aktuellen Hochlauf des Rechners siehst Du mit: journalctl -b 0
Das Systemlog für den davor liegenden Hochlauf entsprechend mit: journalctl -b -1
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Ja, ok, danke. Aber wie hilft mir das? Tatsächlich war der vorletzte "Hochlauf" am 10.02.21, der letzte heute nach dem Hängenbleiben 15.03.21 10:20. Aber damit weiß ich doch noch lange nicht, wieso er um 10:10 oder 10:15 "eingefroren" war. Immer wenn die Kiste hängengeblieben ist und man sie (mit dem Netzschalter ☹ ) aus- und wieder eingeschaltet hat, läuft sie ja ganz normal hoch. Oder was übersehe ich jetzt?
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
Nachtrag: Müsste da etwas in den gelben oder roten Einträgen stehen? Macht es Sinn, dass ich die einmal kopiere und hier einstelle?
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
Müsste da etwas in den gelben oder roten Einträgen stehen?
Kommt darauf an, wie hart der Absturz war. Die Logateien sind auch nur "Software". https://wiki.ubuntuusers.de/Logdateien/
Webmin
Würde ich nochmal nachlesen, "Ubuntu" hat da offenbar mehr Probleme als nur "Sicherheit". Ich kenne übrigens auch nur "Sicherheit, ewig her! 💡
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
hakel2020 schrieb: Müsste da etwas in den gelben oder roten Einträgen stehen?
Kommt darauf an, wie hart der Absturz war. Die Logateien sind auch nur "Software".
Sollte ich die gelben und roten Zeilen hier mal posten? Oder ist das eher unerwünscht? Gibt es denn auch ein "laufendes Protokoll", sozusagen bis zum Hängenbleiben? Ich habe den "Eindruck", dass das kein "harter Knall" war, denn ich war per SSH auf der Kiste, und die wurde "immer träger", reagierte aber noch, wenn auch seeehr langsam, und dann war irgendwann Schluss. Vielleicht "schaukelt" sich da ja irgendwas auf, bis es kracht. Aber ist das überhaupt denkbar? Denkbar, dass "in der Hardware" ein Problem immer schwerer wird, bis die Kiste steht? (Dabei würde ich Temperatur ausschließen, denn das würde ja kaum erst nach 32 Tagen auftreten, oder?) hakel2020 schrieb: https://wiki.ubuntuusers.de/Logdateien/
Puh, muss ich mal durchsuchen. Oder habt Ihr einen Vorschlag für mich? (Ich bin nicht zu faul, eher ein bisschen "erschlagen".) hakel2020 schrieb: Webmin
Würde ich nochmal nachlesen, "Ubuntu" hat da offenbar mehr Probleme als nur "Sicherheit". Ich kenne übrigens auch nur "Sicherheit, ewig her! 💡
Ich würde ein Softwareproblem mit Webmin ausschließen, denn wie gesagt, blieb die Kiste auch als Windows-Server hängen. Es ist eher umgekehrt, dass sich meine Hoffnung, Windows wäre - wie so oft - der Grund gewesen, zerschlagen hat. (Und meine anderen Hosts in gleicher Konfiguration lauen problemlos. Einziger Unterschied: alle anderen Hosts haben Intel-CPUs, dies ist meine einzige AMD.)
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
hakel2020 schrieb: https://wiki.ubuntuusers.de/Logdateien/
/var/log/kern.log könnte die richtige Datei sein? Da steht "kurz" vor dem Hänger (ca. 10:20) etwas wie
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44 | Mar 15 10:01:06 svh-dev kernel: [2823646.333558] systemd-logind invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Mar 15 10:01:06 svh-dev kernel: [2823646.333561] CPU: 9 PID: 1241 Comm: systemd-logind Tainted: G OE 5.4.0-65-generic #73-Ubuntu
Mar 15 10:01:06 svh-dev kernel: [2823646.333562] Hardware name: Micro-Star International Co., Ltd. MS-7A33/X370 GAMING PRO (MS-7A33), BIOS 4.D0 09/25/2018
Mar 15 10:01:06 svh-dev kernel: [2823646.333563] Call Trace:
Mar 15 10:01:06 svh-dev kernel: [2823646.333569] dump_stack+0x6d/0x9a
Mar 15 10:01:06 svh-dev kernel: [2823646.333572] dump_header+0x4f/0x1eb
Mar 15 10:01:06 svh-dev kernel: [2823646.333573] oom_kill_process.cold+0xb/0x10
Mar 15 10:01:06 svh-dev kernel: [2823646.333575] out_of_memory.part.0+0x1df/0x3d0
Mar 15 10:01:06 svh-dev kernel: [2823646.333576] out_of_memory+0x6d/0xd0
Mar 15 10:01:06 svh-dev kernel: [2823646.333578] __alloc_pages_slowpath+0xd5e/0xe50
Mar 15 10:01:06 svh-dev kernel: [2823646.333581] __alloc_pages_nodemask+0x2d0/0x320
Mar 15 10:01:06 svh-dev kernel: [2823646.333583] alloc_pages_current+0x87/0xe0
Mar 15 10:01:06 svh-dev kernel: [2823646.333585] __page_cache_alloc+0x72/0x90
Mar 15 10:01:06 svh-dev kernel: [2823646.333586] pagecache_get_page+0xbf/0x300
Mar 15 10:01:06 svh-dev kernel: [2823646.333588] filemap_fault+0x6b2/0xa50
Mar 15 10:01:06 svh-dev kernel: [2823646.333590] ? xas_load+0xd/0x80
Mar 15 10:01:06 svh-dev kernel: [2823646.333593] ? mem_cgroup_charge_statistics+0x51/0xe0
Mar 15 10:01:06 svh-dev kernel: [2823646.333594] ? xas_load+0xd/0x80
Mar 15 10:01:06 svh-dev kernel: [2823646.333595] ? xas_find+0x17f/0x1c0
Mar 15 10:01:06 svh-dev kernel: [2823646.333596] ? filemap_map_pages+0x24c/0x380
Mar 15 10:01:06 svh-dev kernel: [2823646.333599] ext4_filemap_fault+0x32/0x46
Mar 15 10:01:06 svh-dev kernel: [2823646.333600] __do_fault+0x3c/0x130
Mar 15 10:01:06 svh-dev kernel: [2823646.333601] do_fault+0x24b/0x640
Mar 15 10:01:06 svh-dev kernel: [2823646.333603] __handle_mm_fault+0x4c5/0x7a0
Mar 15 10:01:06 svh-dev kernel: [2823646.333605] handle_mm_fault+0xca/0x200
Mar 15 10:01:06 svh-dev kernel: [2823646.333608] do_user_addr_fault+0x1f9/0x450
Mar 15 10:01:06 svh-dev kernel: [2823646.333609] __do_page_fault+0x58/0x90
Mar 15 10:01:06 svh-dev kernel: [2823646.333611] do_page_fault+0x2c/0xe0
Mar 15 10:01:06 svh-dev kernel: [2823646.333612] page_fault+0x34/0x40
Mar 15 10:01:06 svh-dev kernel: [2823646.333615] RIP: 0033:0x7f53176d0154
Mar 15 10:01:06 svh-dev kernel: [2823646.333619] Code: Bad RIP value.
Mar 15 10:01:06 svh-dev kernel: [2823646.333620] RSP: 002b:00007ffe97f3e950 EFLAGS: 00010246
Mar 15 10:01:06 svh-dev kernel: [2823646.333621] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001
Mar 15 10:01:06 svh-dev kernel: [2823646.333622] RDX: 0000000000000003 RSI: 0000000000000000 RDI: 000055b84dc33f60
Mar 15 10:01:07 svh-dev kernel: [2823646.333622] RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000001b
Mar 15 10:01:07 svh-dev kernel: [2823646.333623] R10: 0000000000000000 R11: 0000000000000202 R12: 000055b84dc30b20
Mar 15 10:01:07 svh-dev kernel: [2823646.333624] R13: 00007f53178732e0 R14: 00007ffe97f3ea98 R15: 00007ffe97f3eab0
Mar 15 10:01:08 svh-dev kernel: [2823646.333625] Mem-Info:
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] active_anon:12 inactive_anon:51 isolated_anon:0
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] active_file:277 inactive_file:94 isolated_file:0
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] unevictable:4781 dirty:0 writeback:25 unstable:0
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] slab_reclaimable:31639 slab_unreclaimable:191793
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] mapped:16094907 shmem:0 pagetables:33799 bounce:0
Mar 15 10:01:08 svh-dev kernel: [2823646.333629] free:81581 free_pcp:561 free_cma:0
|
und | Mar 15 10:01:08 svh-dev kernel: [2823646.334109] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=VBoxHeadless,pid=472383,uid=1000
Mar 15 10:01:08 svh-dev kernel: [2823646.334159] Out of memory: Killed process 472383 (VBoxHeadless) total-vm:10401216kB, anon-rss:0kB, file-rss:8576936kB, shmem-rss:0kB, UID:1000 pgtables:17236kB oom_score_adj:0
Mar 15 10:01:08 svh-dev kernel: [2823646.335760] oom_reaper: reaped process 472383 (VBoxHeadless), now anon-rss:0kB, file-rss:8574332kB, shmem-rss:0kB
Mar 15 10:01:08 svh-dev kernel: [2823646.336482] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55e9e64ac0,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336528] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55c9299c60,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336550] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55c8f16cf0,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336572] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55c878ee10,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336650] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55c880fb20,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336670] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55b3e34840,,0x18); uCmd=0xc0305698!
Mar 15 10:01:08 svh-dev kernel: [2823646.336722] VBoxDrvLinuxIOCtl: copy_to_user(0x7f55c860cdc0,,0x18); uCmd=0xc0305698!
|
sowie (vor und nach dem Neustart) 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 | Mar 15 10:03:53 svh-dev kernel: [2823722.320281] usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:04:47 svh-dev kernel: [2823726.672280] usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:05:38 svh-dev kernel: [2823726.976239] usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:06:39 svh-dev kernel: [2823727.280333] usb 1-10: reset high-speed USB device number 2 using xhci_hcd
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] Linux version 5.4.0-66-generic (buildd@lgw01-amd64-039) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021 (Ubuntu 5.4.0-66.74-generic 5.4.86)
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.4.0-66-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] KERNEL supported cpus:
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] Intel GenuineIntel
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] AMD AuthenticAMD
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] Hygon HygonGenuine
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] Centaur CentaurHauls
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] zhaoxin Shanghai
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] BIOS-provided physical RAM map:
Mar 15 10:24:48 svh-dev kernel: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
|
Kann man da etwas "herauslesen"? Ich kann das leider (noch) nicht... 😕
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
wurde "immer träger"
Das hört sich doch gut an. 👍 Also würgt irgendein Serverdienst langsam dein System ab. Da solltest du wirklich etwas in den Logs finden. Als erfahrener Admin solltest du doch da einen Verdacht haben. Schwellen da unter var/log Ordner an ? Das ist deine Vorarbeit, du sitzt vor der Kiste! Klar kannst du das hier veröffentlichen. Frage ist halt, ob du im richtigen Subforum bist.
Webmin
Keine Ahnung, das war seinerzeit ein richtiges "Trommelfeuer". Ewig her ...
Micro-Star International Co., Ltd. MS-7A33/X370 GAMING PRO
Was ist das denn ... ? Server ... ?
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
hakel2020 schrieb: wurde "immer träger"
Das hört sich doch gut an. 👍 Also würgt irgendein Serverdienst langsam dein System ab. Da solltest du wirklich etwas in den Logs finden. Als erfahrener Admin solltest du doch da einen Verdacht haben. Schwellen da unter var/log Ordner an ?
Aber - wie schon geschrieben - das "gleiche" Verhalten hatte ich schon, als die Kiste noch Win2k12 war, also wird es wohl kein Linux-Problem sein? hakel2020 schrieb: Klar kannst du das hier veröffentlichen. Frage ist halt, ob du im richtigen Subforum bist.
Deshalb fragte ich oben danach. Gibt es ein passenderes? hakel2020 schrieb: Micro-Star International Co., Ltd. MS-7A33/X370 GAMING PRO
Was ist das denn ... ? Server ... ?
Die Frage verstehe ich nicht. Ich habe Ubuntu 20.04 "Server" installiert, dazu Webmin und Virtualbox.
Wo ist das Problem? Dass das Motherboard einen seltsamen Namen hat? –- Aber wo Du sagst, jemand saue den Speicher voll, im Kernel-Log steht "unendlich oft" die Zeile
| Mar 14 00:09:31 svh-dev kernel: [2701765.311764] usb 1-10: reset high-speed USB device number 2 using xhci_hcd
|
Kann das ein Problem sein?
|
hakel2020
Anmeldungsdatum: 21. Januar 2021
Beiträge: 1169
|
oom_kill_process.cold
Kann es sein, daß dein System tatsächlich Out of Memory ist ? Hast du mal ganz ordinär einen memtest gemacht ?
Gaming
Diese MBs haben oft viele Features und Schnittstellen, die man auf einem Server eigentlich nicht möchte. Was nicht vorhanden ist, kann keinen Ärger machen. Prüf' wie gesagt, ob der Log Ordner "voll" läuft.
reset high-speed USB device number 2 using xhci_hcd
Mit USB ist nie zu spaßen ... mußt du beheben. Kann ich nicht beurteilen, ob du das benötigst.
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3547
|
Out of memory: Killed process 472383 (VBoxHeadless) total-vm:10401216kB Ich habe einen Virtualisierungshost
Wieviel RAM ist denn da drin? Swap vorhanden? Und wieviel RAM hast den den VM's in Summe zugeteilt? Evtl. überbucht, und wenn alle VM irgendwann den zugeteilten RAM anfordern, rumpelt es?
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
"memtest" mache ich morgen früh. Die Kiste hat 64 GB, es gibt neun VMS, die zusammen 46 GB haben, beim Hänger liefen aber nur sieben davon mit insgesamt 40 GB. "Gaming Features" muss ich mal nachsehen, ob und was man da abschalten kann, aber nochmal: gleicher Fehler als Windows-Server. Was bedeutet denn die "USB-Meldung"? Wie kann ich die "wegbekommen"?
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3547
|
aber nochmal: gleicher Fehler als Windows-Server
Das Ganze riecht irgenwie nach Hardwareproblem. Neuestes UEFI ist drauf? Nach dem Flashen immer Load default settings aufrufen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Emma2 schrieb: [–] Mar 15 10:01:06 svh-dev kernel: [2823646.333558] systemd-logind invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Wenn der Out-of-Memory-Killer (oom-killer) losgeschickt wird, hat das System ein massives Problem mit der Speicherverwaltung. Von einer bestimmten Blockgröße gibt es gibt keine freien Speicherblöcke. Ursache kann ein amoklaufendes Programm sein, welches in einer Endlosschleife Speicher anfordert. In diesen Fällen wird oom-killer beaufragt, den Übeltäter zu beenden, sofern dieser identifizierbar ist oder ersatzweise einen anderen Prozess, sofern dessen Tod für das System Linderung erwarten lässt. In Deinem Fall …
[…] Mar 15 10:01:08 svh-dev kernel: [2823646.334109] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-3.scope,task=VBoxHeadless,pid=472383,uid=1000
Mar 15 10:01:08 svh-dev kernel: [2823646.334159] Out of memory: Killed process 472383 (VBoxHeadless) total-vm:10401216kB, anon-rss:0kB, file-rss:8576936kB, shmem-rss:0kB, UID:1000 pgtables:17236kB oom_score_adj:0
… erwischt er den Virtualisierer.
|
Emma2
(Themenstarter)
Anmeldungsdatum: 28. Dezember 2018
Beiträge: 438
|
dingsbums schrieb: Das Ganze riecht irgenwie nach Hardwareproblem. Neuestes UEFI ist drauf?
Da habe ich mich noch nicht rangetraut. dingsbums schrieb: Nach dem Flashen immer Load default settings aufrufen.
Das kann ich ja auch einfach mal so machen (obwohl ich mich nicht erinnere, bei der Ersteinrichtung etwas verstellt zu haben außer Speichergeschwindigkeit).
|