Puncte:1

/dev/shm este plin la utilizare 100%, dar nu are fișiere mari

drapel aw

Am actualizat recent la Ubuntu 20.04.3 (kernel 5.11.0-34-generic #36~20.04.1-Ubuntu SMP), deci poate fi o eroare. După câteva ore de utilizare, partiția de memorie partajată se umple. Conform df, partiție /dev/shm are 16G de date în el:

Filesystem Size Used Avail Use% Montat pe
...
tmpfs 16G 16G 0 100% /dev/shm
...

Încercarea de a scrie un fișier nou pe acea partiție eșuează:

$ echo "foobar" > /dev/shm/foobar.txt
bash: echo: eroare de scriere: nu a mai rămas spațiu pe dispozitiv

Cu toate acestea, când mă uit la fișierele din acea partiție, fișierele folosesc doar aproximativ 170K:

$ du -h /dev/shm/*
0 /dev/shm/foobar.txt
4.0K /dev/shm/sem.CiscoAcMemoryLock
4.0K /dev/shm/sem.CiscoAcNamedEventNVM
4.0K /dev/shm/sem.CiscoAcNamedEventOpenDNS
4.0K /dev/shm/sem.CiscoAcNamedEventPostureISE
156K /dev/shm/tmp

Observ că se întâmplă acest lucru deoarece google-chrome aruncă nucleul și nu pot reporni Chrome până când nu există spațiu în /dev/shm, și singura modalitate pe care am găsit-o de a recupera memoria este repornirea.

Cum pot afla ce folosește spațiul în /dev/shm?

drapel aw
După încercări și erori, am descoperit că acest lucru a fost cauzat de google-chrome. Pot să o rezolv rulând Chrome cu opțiunea „--disable-dev-shm-usage”. Sunt încă interesat de răspunsuri care ar fi putut indica Chrome drept vinovat.
Puncte:1
drapel cn

Fișierele există pe un sistem de fișiere atâta timp cât au încă o intrare în director sau sunt menținute deschise printr-un proces curent. Alergare du -h /dev/shm/ (adăugând * exclude fișierele care încep cu .) va arăta doar primul.

De asemenea, trebuie să fugi sudo lsof /dev/shm, care arată fișierele deschise curent pe acel sistem de fișiere.

De exemplu:

COMANDA PID UTILIZATOR TIP FD DIMENSIUNEA DISPOZITIV/OPRIT NUMELE NODULUI
QtWebEngi 654092 utilizator DEL REG 0,31 2610 /dev/shm/.org.chromium.Chromium.eAzBpJ
QtWebEngi 654092 utilizator DEL REG 0,31 2613 /dev/shm/.org.chromium.Chromium.eY7oKn
QtWebEngi 654092 utilizator DEL REG 0,31 2624 /dev/shm/.org.chromium.Chromium.zuBEOF
QtWebEngi 654092 utilizator 22u REG 0,31 144 2610 /dev/shm/.org.chromium.Chromium.eAzBpJ (șters)
QtWebEngi 654092 utilizator 29u REG 0,31 144 2613 /dev/shm/.org.chromium.Chromium.eY7oKn (șters)
QtWebEngi 654092 utilizator 46r REG 0,31 1048576 2624 /dev/shm/.org.chromium.Chromium.zuBEOF (șters)

Rânduri care se termină cu (șters) nu va fi găsit de du, dar va ocupa în continuare spațiu atâta timp cât orice proces păstrează acel fișier.

drapel aw
Bună sugestie și sunt sigur că va fi util pentru alții, dar pentru mine, când opresc toate procesele care apar cu comanda lsof și lsof nu arată nimic atașat la /dev/shm și la directorul /dev/shm este complet gol, df arată că partiția este 100% plină.
Puncte:0
drapel in

Am aceeași problemă cu Ubuntu 20.04 LTS (versiunea de kernel 5.11.0.34.36, actualizată cu update-ul la 5.11.0.36.40). După actualizarea nucleului la cea mai recentă versiune, problema a fost rezolvată. Prin posta de la Marc Gil Sendra, vezi https://unix.stackexchange.com/questions/654004/ubuntu-20-04-problems-with-chrome-teams-visual-studio-code-maybe-related-wi din 14.7.2021 a rezolvat problema cu actualizarea kernel-ului la versiunea 5.12.10. eu folosesc https://linuxhint.com/install-upgrade-linux-kernel-ubuntu-linux-mint/ pentru a face upgrade la versiunea 5.14.8-051408-generic și problema pare să fie rezolvată.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.