Re: pregunta sobre el nucli Linux
Hola, Julio > em recomaneu per a ordinadors d'alumnes de cicles no posar swap? Si tens molta RAM segurament no us calgui. En alguns casos la swap fa de coixí i permet que el sistema o els processos que consumeixen els recursos no morin inútilment després d'hores, dies o setmanes de feina. Si no us importa que el sistema mati els processos en pic es passin de la ratlla, aleshores no crec que us calgui tenir swap. > he pensat que el dia que decideixi no tenir-la trobaré un > programa antic i important de Murphy amb un if que m'enviarà > a l'infern si no troba la swap. Això no hauria de passar i en cas que passés seria un cas digne d'estudi. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: pregunta sobre el nucli Linux
>> Cap programa no t'hauria de donar mai cap incidència pel fet de no tenir >> memòria d'intercanvi (Swap) a la unitat interna de l'ordinador. La >> pràctica totalitat dels programes deleguen la gestió de memòria al nucli >> del sistema operatiu, que és el què gestiona la diferència entre memòria >> real (RAM) i memòria virtual (Swap), però ho presenta tot davant els >> programes com a «memòria». >> >> Per tant, pots ometre perfectament l'ús d'espai d'intercanvi (swap) si >> creus que amb la quantitat disponible de memòria RAM els programes n'han >> de fer prou tots els dies. >> > Sí, entenc que així hauria de ser, però he vist tantes coses curioses ... :) > >> Pel què fa a la hibernació: >> https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition >> El què no sé és si es pot fer això sense utilitzar el fitxer com a «Swap». >> > > Si poseu a /etc/sysctl.conf > > vm.swappiness=0 > > els processos no usaran el swap però sí que es podrà usar per a la > hibernació. > > Font: > > > https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-debian-10 > > Molt interessant, gràcies a tots dos. -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: pregunta sobre el nucli Linux
El dl., 4 d’oct. 2021, 18:03, Narcis Garcia va escriure: > El 3/10/21 a les 20:57, Julio Amorós ha escrit: > > > > > > > > > > El problema és quan el sistema es queda sense memòria i comença a fer > > servir swap el funcionament es s'alenteix tant que el sistema queda > > inutilitzable, fins al punt que no és possible ni tan sols matar el > > procés manualment. Suposo que si t'esperes suficientment > l'oom-killer > > l'acabaria matant, però jo mai he tingut tanta paciència. > Personalment > > he optat per no tenir swap, per evitar aquestes situacions. > > > > Salutacions. > > > > Tot i que se m'escapa algun concepte trobo interessantíssim el que > > entenc. Desviant-me una mica del tema i entenen que no hi ha una > > resposta universal, com bé diu Eloy ni per a un mateix usuari, em > > recomaneu per a ordinadors d'alumnes de cicles no posar swap? > > A banda de que la swap vagi bé per a la hibernació, he pensat que el dia > > que decideixi no tenir-la trobaré un programa antic i important de > > Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però > > potser són paranoies. > > Vagi bé > > Julio > > > > Cap programa no t'hauria de donar mai cap incidència pel fet de no tenir > memòria d'intercanvi (Swap) a la unitat interna de l'ordinador. La > pràctica totalitat dels programes deleguen la gestió de memòria al nucli > del sistema operatiu, que és el què gestiona la diferència entre memòria > real (RAM) i memòria virtual (Swap), però ho presenta tot davant els > programes com a «memòria». > > Per tant, pots ometre perfectament l'ús d'espai d'intercanvi (swap) si > creus que amb la quantitat disponible de memòria RAM els programes n'han > de fer prou tots els dies. > > Pel què fa a la hibernació: > https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition > El què no sé és si es pot fer això sense utilitzar el fitxer com a «Swap». > Si poseu a /etc/sysctl.conf vm.swappiness=0 els processos no usaran el swap però sí que es podrà usar per a la hibernació. Font: https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-debian-10 > -- > > > __ > I'm using this express-made address because personal addresses aren't > masked enough at this mail public archive. Public archive administrator > should fix this against automated addresses collectors. > >
Re: pregunta sobre el nucli Linux
El 3/10/21 a les 20:57, Julio Amorós ha escrit: > > > > > El problema és quan el sistema es queda sense memòria i comença a fer > servir swap el funcionament es s'alenteix tant que el sistema queda > inutilitzable, fins al punt que no és possible ni tan sols matar el > procés manualment. Suposo que si t'esperes suficientment l'oom-killer > l'acabaria matant, però jo mai he tingut tanta paciència. Personalment > he optat per no tenir swap, per evitar aquestes situacions. > > Salutacions. > > Tot i que se m'escapa algun concepte trobo interessantíssim el que > entenc. Desviant-me una mica del tema i entenen que no hi ha una > resposta universal, com bé diu Eloy ni per a un mateix usuari, em > recomaneu per a ordinadors d'alumnes de cicles no posar swap? > A banda de que la swap vagi bé per a la hibernació, he pensat que el dia > que decideixi no tenir-la trobaré un programa antic i important de > Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però > potser són paranoies. > Vagi bé > Julio > Cap programa no t'hauria de donar mai cap incidència pel fet de no tenir memòria d'intercanvi (Swap) a la unitat interna de l'ordinador. La pràctica totalitat dels programes deleguen la gestió de memòria al nucli del sistema operatiu, que és el què gestiona la diferència entre memòria real (RAM) i memòria virtual (Swap), però ho presenta tot davant els programes com a «memòria». Per tant, pots ometre perfectament l'ús d'espai d'intercanvi (swap) si creus que amb la quantitat disponible de memòria RAM els programes n'han de fer prou tots els dies. Pel què fa a la hibernació: https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition El què no sé és si es pot fer això sense utilitzar el fitxer com a «Swap». -- __ I'm using this express-made address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: pregunta sobre el nucli Linux
> El problema és quan el sistema es queda sense memòria i comença a fer > servir swap el funcionament es s'alenteix tant que el sistema queda > inutilitzable, fins al punt que no és possible ni tan sols matar el > procés manualment. Suposo que si t'esperes suficientment l'oom-killer > l'acabaria matant, però jo mai he tingut tanta paciència. Personalment > he optat per no tenir swap, per evitar aquestes situacions. > > Salutacions. > > Tot i que se m'escapa algun concepte trobo interessantíssim el que entenc. Desviant-me una mica del tema i entenen que no hi ha una resposta universal, com bé diu Eloy ni per a un mateix usuari, em recomaneu per a ordinadors d'alumnes de cicles no posar swap? A banda de que la swap vagi bé per a la hibernació, he pensat que el dia que decideixi no tenir-la trobaré un programa antic i important de Murphy amb un if que m'enviarà a l'infern si no troba la swap. Però potser són paranoies. Vagi bé Julio -- __ - El 2003 el català era la llengua habitual del 46 % dels catalans. Al 2018 només del 36 %. Si els castellanoparlants no actuem, desapareixerà. - El 3 de novembre representa el moment de l'any en el que les dones deixen de cobrar en comparació amb els homes. Hem d’ajudar a les dones a eliminar aquesta data. - L’administració pública cada any es gasta milions d’euros en llicències de programari privatiu. Utilitzant programari lliure estalviem costos i incentivem l’economia local. *La neutralitat davant les desigualtats acaba accentuant-les.*
Re: pregunta sobre el nucli Linux
2021-10- 3, 03:12 (+0200); Jordi Miguel escriu: > Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, > segons el que ens expliquen probablement hauria d'haver passat, però > també és possible que no s'hagués exhaurit tota la memòria sinó que > s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha > arribat a cridar el oom-killer. En aquest escenari el Firefox > intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo > que ha decidit l'usuari de la màquina. El problema és quan el sistema es queda sense memòria i comença a fer servir swap el funcionament es s'alenteix tant que el sistema queda inutilitzable, fins al punt que no és possible ni tan sols matar el procés manualment. Suposo que si t'esperes suficientment l'oom-killer l'acabaria matant, però jo mai he tingut tanta paciència. Personalment he optat per no tenir swap, per evitar aquestes situacions. Salutacions.
Re: pregunta sobre el nucli Linux
El 3/10/21 a les 3:12, Jordi Miguel ha escrit: [...] Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, segons el que ens expliquen probablement hauria d'haver passat, però també és possible que no s'hagués exhaurit tota la memòria sinó que s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo que ha decidit l'usuari de la màquina. Per això suggeria desactivar la swap, per evitar el problema del bolcat a disc: el oom-killer no saltarà fins que estigui també tota la swap plena, i si està sobre un disc magnètic doncs trigarà una bona estona a emplenar-la, i mentrestant el sistema no serà responsiu. Sobre els límits per procés en sistemes compartits, com bé s'ha dit és configurable però alhora no hi ha una configuració que serveixi per a tothom. Jo mateix, quan faig servir l'ordinador durant el dia sí que voldria evitar que un únic procés es desmadrés i em tirés avall tota la màquina, però si el deixo funcionant durant la nit amb alguna feina computacionalment costosa, que agafi tots els recursos que pugui, si la resta s'alenteix ben poc que em preocupa mentre dormo... és que ni una "solució universal" pot ser vàlida ni tan sols per al mateix usuari segons l'hora del dia.
Re: pregunta sobre el nucli Linux
Hola, Potser no ha quedat clar com ho he explicat, intento fer-ho millor. Al que m'estava referint és que el oom-killer està protegint el sistema contra la denegació de servei que provocaria que no hi hagi memòria disponible per un procés (d'usuari). En el cas d'esgotar tota la memòria i solicitar-ne més el oom-killer s'invocaria alliberant memòria a base de matar un algún procés (segons unes regles predefinides). És a dir, contesta la pregunta que ha formulat l'Alex: (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? Sobre l'enunciat de la pregunta hauriem d'aclarir també que el fet que un procés consumeixi tota la memòria del sistema no es intrínsecament dolent, per tant prohibir-ho per tots els casos no té sentit. Un usuari podria tenir una màquina que executa un sol procés que utilitza exactament tota la memoria però sense passar-se. Creieu que s'ha de denegar aquest comportament unilateralment?? Interpreto que quan et refereixes al "problema del company" vols dir que el Firefox (o qualsevol altre procés d'usuari de la máquina) tingui la possibilitat d'utilitzar tota la RAM del sistema. Això seria una cosa diferent a la denegació de servei per quedar-te sense RAM (i swap en cas d'haver-hi) i per gestionar-ho hi ha altres eines com ulimit, cgroups, ... En la majoria de distribucions (incloses Debian i Ubuntu) els límits per defecte són molt laxos però, no és responsabilitat de l'usuari (administrador) de la máquina configurar aquesta com desitgi?? Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, segons el que ens expliquen probablement hauria d'haver passat, però també és possible que no s'hagués exhaurit tota la memòria sinó que s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha arribat a cridar el oom-killer. En aquest escenari el Firefox intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo que ha decidit l'usuari de la màquina. T'encaixa ara?? Contestant a les teves preguntes sobre el codi del OOM: El significat que has suposat de les abreviacions és correcte. En quan al trosset de codi [2], l'objectiu de la funció on està escrit això és donar una puntuació pel procés sobre el que li han preguntat. Aquesta puntuació és una funció (en el sentit matemàtic) que utiliza diferents paràmetres sobre l'espai de memòria del procés (rss, swap, taula de pàgines,...). Per poder consultar aquestes dades necessita el punter a l'esctructura mm_struct i per trobar aquest punter crida a la funció "find_lock_task_mm()". Salutacions, Jordi -- -- Para ser realmente grande, hay que estar con la gente, no por encima de ella. El sáb, 2 oct 2021 a las 20:14, pedeb () escribió: > > Hola Jordi, > > sembla que això de oom_killer és una cosa que té múltiples > configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i > no veig gaire raonable per evitar el problema que comenta el company > [0], o estic equivocat. > > també he trobat [1] (això ho trobo molt interessant Alex) > > i independentment d'això, ja que has apuntat el codi font, si em pots > ajudar a entendre: > > què vol dir literalment la variable adj: adjustment? > > què vol dir literalment la mm: memory management?, ien aquest context [2] ? > > Gràcies! > Pedro > > [0] > https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ > https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html >que ve de > https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/ > > [1] > https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02 > > [2] > p = find_lock_task_mm(p); > if (!p) > return LONG_MIN; > > On 10/2/21 3:02 PM, Jordi Miguel wrote: > > Hola, > > > > Sobre el tema del límit d'usuaris per les aplicacions de Google Drive > > (Docs, Sheets, Slides), Google diu el següent: > > > > Share & collaborate on a file with more than 100 people > > Up to 100 people with view, edit, or comment permissions can work on a > > Google Docs, Sheets, or Slides file at the same time. When more than > > 100 people are accessing a file, only the owner and some users with > > editing permissions can edit the file. > > > > Podeu veure la informació completa aquí[1] amb les solucions que > > proposen per compartir amb més de 100 persones. Potser seria > > interessant que ens comentessis com vas compartir aquesta presentació: > > quins permisos tenies tu sobre la presentació? els alumnes tenien el > > mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes > > només tenia permisos com a lector ?? Pots reproduir el problema si > > comparteixes la presentació de la manera que es proposa a la > > documentació de Google ?? > > > > Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino > > que tindràs extensions i/o temes carregats. El primer pas seria >
Re: pregunta sobre el nucli Linux
Hola Jordi, sembla que això de oom_killer és una cosa que té múltiples configuracions i que s'ha d'ajustar, però que té uns ajustos genèrics i no veig gaire raonable per evitar el problema que comenta el company [0], o estic equivocat. també he trobat [1] (això ho trobo molt interessant Alex) i independentment d'això, ja que has apuntat el codi font, si em pots ajudar a entendre: què vol dir literalment la variable adj: adjustment? què vol dir literalment la mm: memory management?, ien aquest context [2] ? Gràcies! Pedro [0] https://www.percona.com/blog/2019/08/02/out-of-memory-killer-or-savior/ https://www.oracle.com/technical-resources/articles/it-infrastructure/dev-oom-killer.html que ve de https://juantrucupei.wordpress.com/2017/04/03/desactivar-oom-killer-out-of-memory-killer/ [1] https://dev.to/msugakov/taking-firefox-memory-usage-under-control-on-linux-4b02 [2] p = find_lock_task_mm(p); if (!p) return LONG_MIN; On 10/2/21 3:02 PM, Jordi Miguel wrote: Hola, Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent: Share & collaborate on a file with more than 100 people Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than 100 people are accessing a file, only the owner and some users with editing permissions can edit the file. Podeu veure la informació completa aquí[1] amb les solucions que proposen per compartir amb més de 100 persones. Potser seria interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la documentació de Google ?? Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino que tindràs extensions i/o temes carregats. El primer pas seria intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ?? Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el consum es dispari. En quant el tema de control de memòria per part del kernel ja has vist en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que la compleix el OOM-killer (out-of-memory killer). Podeu veure com funciona mirant el codi font [2]. Quan aquest procés s'activa registra el que ha fet al dmesg. Si realment es va consumir tota la memòria pots revisar quin o quins processos va matar el OOM-killer mirant els logs. [1] https://support.google.com/drive/answer/2494822?hl=en [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195 Salutacions, Jordi -- El sáb, 2 oct 2021 a las 13:28, Àlex () escribió: Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No és tant quan 100 persones obren el document, com quan un d'ells fa clic al botó d'iniciar reproducció. Quan moltes persones tenen el document obert el sistema no tenía més que 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per què? No ho sé. Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. Fa uns dies que veig que els llocs de Google funcionen millor amb Chromium que amb Firefox. Potser només passa amb Firefox. Però de les tres preguntes que sorgeixen ... (1) Per què passa això a Google Slides ? (2) Per què els navegadors no controlen quan una pestanya es menja tota la RAM del sistema per avisar l'usuari si la vol bloquejar ? (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
Re: pregunta sobre el nucli Linux
El 2/10/21 a les 13:28, Àlex ha escrit: > Fa uns dies que veig que els llocs de Google funcionen millor amb > Chromium que amb Firefox. Potser només passa amb Firefox. Naturalment quan es tracta d'aquest tipus de corporació. També passa que els llocs de Microsoft funcionen millor amb navegadors de Microsoft que amb d'altres. -- __ I'm using this express-made address because personal addresses aren't masked enough at this mail public archive. Public archive administrator should fix this against automated addresses collectors.
Re: pregunta sobre el nucli Linux
Bones, No coneixo massa tema però sé que els contenidors i tecnologies com docker i kubernetes fan servir cgroups per controlar els recursos que es reserven per cada contenidor: https://www.man7.org/linux/man-pages/man7/cgroups.7.html signature.asc Description: PGP signature
Re: pregunta sobre el nucli Linux
Hola, Sobre el tema del límit d'usuaris per les aplicacions de Google Drive (Docs, Sheets, Slides), Google diu el següent: Share & collaborate on a file with more than 100 people Up to 100 people with view, edit, or comment permissions can work on a Google Docs, Sheets, or Slides file at the same time. When more than 100 people are accessing a file, only the owner and some users with editing permissions can edit the file. Podeu veure la informació completa aquí[1] amb les solucions que proposen per compartir amb més de 100 persones. Potser seria interessant que ens comentessis com vas compartir aquesta presentació: quins permisos tenies tu sobre la presentació? els alumnes tenien el mateix enllaç i, per tant, permisos que tu? o l'enllaç dels alumnes només tenia permisos com a lector ?? Pots reproduir el problema si comparteixes la presentació de la manera que es proposa a la documentació de Google ?? Sobre el motiu pel qual Firefox consumeix tota la memòria RAM, imagino que tindràs extensions i/o temes carregats. El primer pas seria intentar reproduir el mateix problema utilitzant el safe mode (e.g. # firefox --safe-mode ) ?? Si en safe mode el Firefox es comporta correctament hauries d'anar activant/desactivant extensions fins que trobis quina provoca que el consum es dispari. En quant el tema de control de memòria per part del kernel ja has vist en la teva cerca per Internet que tens diverses opcions disponibles (ulimit, cgroups, ...). La funció de protecció que busques opino que la compleix el OOM-killer (out-of-memory killer). Podeu veure com funciona mirant el codi font [2]. Quan aquest procés s'activa registra el que ha fet al dmesg. Si realment es va consumir tota la memòria pots revisar quin o quins processos va matar el OOM-killer mirant els logs. [1] https://support.google.com/drive/answer/2494822?hl=en [2] https://github.com/torvalds/linux/blob/master/mm/oom_kill.c#L195 Salutacions, Jordi -- El sáb, 2 oct 2021 a las 13:28, Àlex () escribió: > > > > Em crida molt l'atenció que Google Slides faci petar el navegador quan > > es comparteix una presentació amb 100 persones. > > > No és tant quan 100 persones obren el document, com quan un d'ells fa > clic al botó d'iniciar reproducció. > > Quan moltes persones tenen el document obert el sistema no tenía més que > 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al > botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per > què? No ho sé. > > Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 > > No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. > > Fa uns dies que veig que els llocs de Google funcionen millor amb > Chromium que amb Firefox. Potser només passa amb Firefox. > > Però de les tres preguntes que sorgeixen ... > > (1) Per què passa això a Google Slides ? > > (2) Per què els navegadors no controlen quan una pestanya es menja tota > la RAM del sistema per avisar l'usuari si la vol bloquejar ? > > (3) Per què un sistema operatiu multiusuari no ve de sortida més > protegit per que el procés d'un usuari no es mengi tota la ram causan > una denegació de servei a la resta ? > > ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1) >
Re: pregunta sobre el nucli Linux
Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No és tant quan 100 persones obren el document, com quan un d'ells fa clic al botó d'iniciar reproducció. Quan moltes persones tenen el document obert el sistema no tenía més que 1 Gb de RAM ocupada entre escriptori i navegador. És quan faig clic al botó d'iniciar presentació qué de sobte demana tota la RAM i peta. Per què? No ho sé. Només ho he reproduit un parell de cops amb Ubuntu 18.04 + Firefox 92.0 No ho he provat amb Chromium . Tampoc ho he provat a Windows ni MacOS. Fa uns dies que veig que els llocs de Google funcionen millor amb Chromium que amb Firefox. Potser només passa amb Firefox. Però de les tres preguntes que sorgeixen ... (1) Per què passa això a Google Slides ? (2) Per què els navegadors no controlen quan una pestanya es menja tota la RAM del sistema per avisar l'usuari si la vol bloquejar ? (3) Per què un sistema operatiu multiusuari no ve de sortida més protegit per que el procés d'un usuari no es mengi tota la ram causan una denegació de servei a la resta ? ... a llarg termini m'interessen més la pregunta (3) ó la (2) que la (1)
Re: pregunta sobre el nucli Linux
El 2/10/21 a les 12:07, Àlex ha escrit: [...] L'atac ha estat amb Google Slides i sembla fàcil de reproduir. Algú em va passar una presentació de Google Slides i, enlloc de passar-ho a pdf, vaig compartir l'enllaç de la presentació amb 25 alumnes. Fins aquí res anormal. Els 25 alumnes van obrir la presentació al seu ordinador. Un alumne per fer la gracia va posar la URL en una pàgina que obria moltes URLs automàticament alhora, així que realment aquella presentació estava oberta o compartida per 100 persones o pestanyes de navegadors. Fins aquí tot funcionava bé. Però en el moment que algú feia clic al botó d'iniciar presentació, Firefox en menys d'un segon reclamava tota la memòria del sistema (16Gb ram + 4 gb swap), i el sistema deixava de respondre. Em crida molt l'atenció que Google Slides faci petar el navegador quan es comparteix una presentació amb 100 persones. No conec l'eina, però venint de Google que en general presumeix de milions d'usuaris, un límit tan baix realment crida l'atenció. Entenc que aquí el problema ve del fet que abans que el nucli comenci a fer "neteja" quan s'exhaureix la memòria, és que precisament l'ha d'exhaurir, i això inclou la swap. El primer que fa és passar a disc la memòria amb menys ús, i mentre ho fa t'alentirà desesperadament l'ordinador. Una possible mitigació que crec que et podria ser útil en el teu escenari seria desactivar la swap. Pots fer-ho en viu, amb "swapoff -a", sense necessitat de cap reinici, i la pots rehabilitar de nou amb "swapon -a", assumint que la tens configurada a /etc/fstab (si tens una configuració personalitzada de swap, passa com a paràmetre el(s) dispositiu(s) de bloc). No t'evita realment l'atac DOS, però sí que penso que et permetria recuperar més ràpidament el control, doncs Firefox acabaria o bé petant per si mateix al no poder aconseguir més memòria o el nucli el mataria per alliberar-ne.
Re: pregunta sobre el nucli Linux
El 1/10/21 a les 23:16, pedeb ha escrit: dona'ns detalls de l'arquitectura: - amb quina eina has fet la presentació (alguna cosa a sobre de firefox, oi? quina) - com visualitzen els alumnes la teva presentació: esteu en una mateixa aula (xarxa local) i ho veuen per un projector o en remot (i els alumnes amb els portàtils) qualsevol descripció adicional que afegeixis millor, en seguretat sempre s'ha de tenir en compte el major detall possible Bones L'atac ha estat curiós i NO ha estat des d'una pàgina que els alumnes controlaven, i us ho explicaré a continuació. Però a mi no m'interesa l'atac sino el fet que qualsevol aplicació sense permisos pugui tirar al terra tot un sistema tan sols reclamant més RAM que la que el sistema té. Es pot tractar una aplicació maliciosa de poques línies, però també pot ser una aplicació normal com un navegador que visita una web que li demana tota la RAM. Si des de fa anys els sistemes operatius per defecte venen protegits contra bombes fork , crec que per defecte també haurien de venir protegits contra aquest altre tipus de problemes, especialment amb lo "irresponsiu" que es torna l'escriptori de Linux quan esgotem la RAM. I si els navegadors per defecte venen protegits contra codi javascript que es torna irresponsiu, també haurien de venir protegits contra codi javascript que fa que la memòria usada pel procés estigui esgotant la memòria del sistema. L'atac ha estat amb Google Slides i sembla fàcil de reproduir. Algú em va passar una presentació de Google Slides i, enlloc de passar-ho a pdf, vaig compartir l'enllaç de la presentació amb 25 alumnes. Fins aquí res anormal. Els 25 alumnes van obrir la presentació al seu ordinador. Un alumne per fer la gracia va posar la URL en una pàgina que obria moltes URLs automàticament alhora, així que realment aquella presentació estava oberta o compartida per 100 persones o pestanyes de navegadors. Fins aquí tot funcionava bé. Però en el moment que algú feia clic al botó d'iniciar presentació, Firefox en menys d'un segon reclamava tota la memòria del sistema (16Gb ram + 4 gb swap), i el sistema deixava de respondre. Suposo que qualsevol atacant pot crear codi maliciós que faci quelcom semblant, i deixar-ho en pàgines d'internet o anuncis inserits en pàgines de tercers. Salutacions Àlex
Re: pregunta sobre el nucli Linux
Hola, Àlex > Avui els meus estudiants de FP han aconseguit tombar amb un > atac DOS l'ordinador amb el que feia una presentació (un Ubuntu > 18.04 completament actualitzat) fent que en menys d'un segon el > Firefox reclamés tota la memòria del sistema (16Gb RAM + 4Gb > swap) Si ha estat el firefox, aleshores entenc que has obert alguna URL que ells havien preparat per aconseguir aquest objectiu, oi? > Hi ha alguna protecció del nucli per quan una aplicació que > s'executa amb permisos d'usuari demani instantàniament tota la > memòria RAM i swap del sistema, causant un atac D.O.S. ? La més senzilla són els límits (per defecte, molt laxos): $ ulimit -a > He trobat això, però no sé si hi ha una manera més senzilla: > > https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process Més senzilla que quina? En aquesta pàgina s'esmenten moltes coses diferents. Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: pregunta sobre el nucli Linux
dona'ns detalls de l'arquitectura: - amb quina eina has fet la presentació (alguna cosa a sobre de firefox, oi? quina) - com visualitzen els alumnes la teva presentació: esteu en una mateixa aula (xarxa local) i ho veuen per un projector o en remot (i els alumnes amb els portàtils) qualsevol descripció adicional que afegeixis millor, en seguretat sempre s'ha de tenir en compte el major detall possible
Re: pregunta sobre el nucli Linux
He trobat això, però no sé si hi ha una manera més senzilla: https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process
pregunta sobre el nucli Linux
Benvolguts/des, Avui els meus estudiants de FP han aconseguit tombar amb un atac DOS l'ordinador amb el que feia una presentació (un Ubuntu 18.04 completament actualitzat) fent que en menys d'un segon el Firefox reclamés tota la memòria del sistema (16Gb RAM + 4Gb swap) Hi ha alguna protecció del nucli per quan una aplicació que s'executa amb permisos d'usuari demani instantàniament tota la memòria RAM i swap del sistema, causant un atac D.O.S. ? Quan jo era prou jove havia una sèrie d'atacs sobre els sistemes operatius Unix que s'anomenaven Bombes Fork ( https://www.geeksforgeeks.org/fork-bomb/ ) que creaven infinits processos, però els sistemes operatius de seguida van corregir això. Entenc que davant d'un programa que amb permisos d'usuari en un instant demana tota la memòria, també hauria d'existir protecció. Gràcies
