Vezi Jurnalele evenimentelor îndreptându-se mai în jos.

Sunt pe Ubuntu Server 21.04, rulând kernelul 5.11.0-1015-raspi pe aarch64.

Care sunt cele mai eficiente lucruri de pregătit pentru a avansa în diagnosticarea acestui lucru data viitoare când se va întâmpla?

Ocazional, după o utilizare intensă, încep să am probleme ciudate, cum ar fi acestea:

• unele procese care nu ar trebui să facă nimic afișează utilizarea 100% a unui singur nucleu top (Acest lucru s-a întâmplat recent cu scripturile bash care se fac bucla pe inotifywait pe fișierele de evenimente dev)
• acestea și o mână de alte procese nu se termină cu ucide -9 (Aș fi presupus că inotifywait pur și simplu se încheie imediat, cu excepția acestui lucru)
• sistemul poate menține serviciile în funcțiune, dar tty-urile pot opri procesarea intrării sau ieșirii, inclusiv tty-ul serial
• swapoff /cale/spre/swap se poate bloca pe termen nelimitat chiar și atunci când nu se mai folosește spațiu de schimb
• închidere systemctl se poate bloca pe termen nelimitat sau sistemul se poate opri parțial și apoi se poate bloca
• luminile tastaturii USB pot să nu mai răspundă
• solicitările de conectare pot aștepta foarte mult timp după introducerea unui utilizator și apoi se blochează după afișarea doar unei părți a solicitării de parolă
• apăsările de taste pot fi abandonate
• uneori, mesaje kernel repetate pe un tty indicând aceeași sarcină blocată
• Când nu răspund la infinit, nu văd nicio panică a nucleului pe o deschidere dmesg --follow, journalctl --follow, sau tty
• Lumina de blocare a majusculelor apare în general nefuncțională pe această mașină. De asemenea, lumina de blocare a majusculelor pare nefuncțională pe aarch64 olimex teres.

Am actualizat recent sistemul și sper că aceste probleme pot scădea, dar aș dori să știu ce mai pot face pentru a ajuta la diagnosticarea sau rezolvarea lor. Am depus efortul de a conecta un cablu serial și am fost foarte surprins de faptul că terminalul serial în sine s-ar putea bloca la nesfârșit la jumătatea ieșirii.

Acest lucru se întâmplă de obicei asociat cu alocare excesivă de swap, în exces de RAM disponibil, dar unele dintre probleme, cum ar fi procesele ciudate care nu vor ucide -9, implică mai mult decât o simplă deplasare a memoriei pentru mine, iar problemele nu dispar atunci când memoria este eliberată, deși nu am experiență cu nucleul Linux.

În mod ideal, aș dori să restrâng problema la un bug în nucleu, o problemă cu hardware-ul meu sau un sistem compromis.

Jurnalele evenimentelor:

2021-08-09

După systemctl izola grafic și systemctl izola multi-utilizator systemd-journal folosește 99% CPU care inundă jurnalul pe care org.gnome.Shell@x11 ​​este în așteptarea opririi. starea systemctl spune că nu există un astfel de serviciu. am incercat jurnalctl | pastebinit. Interfața a încetat să mai răspundă înainte de a primi adresa URL, mă tem.

Aceasta nu pare să fie o problemă de memorie virtuală de data aceasta, dar iată ieșirile de memorie pe care le-am primit înainte de a îngheța:

liber -h: https://paste.ubuntu.com/p/3c5tSTgGc4 (acesta a fost luat în timp ce a fost anulat; s-a terminat de deschimbat)

sysctl vm.swappiness: https://paste.ubuntu.com/p/cpvJw4Nd8f

La 10:29 UTC, sesiunea mea tmux a înghețat. Am trecut la tty3 și am încercat să mă autent. Tty s-a blocat afișând parola. La ora 10:32 UTC, ventilatorul s-a învârtit timp de aproximativ 1 minut.

Am un sistem offline conectat la terminalul serial cu dmesg deschis. Ultimele rânduri sunt legate de rfkill, copiate manual pe telefonul meu mobil de mai jos:

[225366.651144] md: verificarea datelor matricei RAID md4
[225724.680213] rfkill: handler de intrare activat
[225745.716506] rfkill: handler de intrare dezactivat
[225751.439369] rfkill: handler de intrare activat

La 10:33, tty3 a afișat „Timpul de conectare a expirat după 60 de secunde”. fără a afișa vreodată o solicitare de parolă. Se blochează fără a afișa o altă solicitare de conectare. Am trimis un ^C la tty-ul serial în jurul orei 10:35 și mi-a fost transmis un ecou, ​​dar nu a fost afișat nicio solicitare de terminal pentru a indica faptul că dmesg a fost întrerupt. 10:36 sau 10:37 serial tty iese/echo un întoarcere de cărucior. Nicio intrare nouă. Ventilatorul se rotește din nou. 10:39 serial tty afișează un prompt, care procesează cheia de retur în așteptare și se blochează din nou. 10:42 au un prompt în serie! 11:00, dar încă încerc să execut orice comenzi din prompt. Este incredibil de lent, dar nu pierde apăsările de taste din memoria tampon (ceea ce mi se întâmplă uneori) 11:01 sistemul răspunde pe serial și tty3. A ucis pastebinit din cauza oom.

lshw -C memorie: https://paste.ubuntu.com/p/x5GMkHRktS