hello
j'ai deux problématiques sur LMDE5:
a/ le OOM (out of memory), à nouveau pour récupérer mes données j'ai du changer d'ordi temporairement, le temps que FF/brave/vivaldi débloquent.. au bout de 72+heures tout s'est débloqué comme si de rien n'était, j'ai pu sauvegarder quelques heures les bloc notes et autres, et redémarrer la bete ; n'est il pas possible de "tuer" les process de navigateurs en "OOM" histoire de sauvegarder sans attendre puis redémarrer?
b/ sous LMDE5, comme c'est arrivé sous mint 18 ya deux ans, la problématique du "lecture uniquement" se pose à novueau à chaque périphérique USB inséré (clés, cartes mémoires), mais le r/w fonctionne très bien sur toutes les partitions du DD interne, ext3 comme ntfs.. why?
merci beaucoup! :)
# reponse D jean pierre
Posté par NeoX . Évalué à 3.
A) tes OOM, c'est justement que la machine n'a plus assez de RAM, l'OS decide alors de kill certaines applications, plutot au hasard
la solution ? ajouter de la RAM, utiliser des applis moins lourdes, etc
B) lecture uniquement sur certains peripheriques mais pas sur d'autres, il faut lire les logs avant/apres insertions du peripherique, si ca se trouve c'est un NTFS qui n'a pas été ejecté correctement du windows à coté, du coup, marqué "impropre" et ton linux veut bien lire, mais pas ecrire dessus.
possible aussi que l'ordi monte la clef en tant que root (mount /dev/clef /point/de/montage) mais qu'ensuite tu essaies d'y acceder depuis ton utilisateur normal avec l'explorateur de fichier
[^] # Re: reponse D jean pierre
Posté par tkr . Évalué à 0.
hello
je te remercie de ta réponse
alors pour le OOM, malheureusement l'ordi a 8GB ce que je trouve cohérent, (deux fois plus que mon ordi ya quatre ans), cependant la problématique étant que les deux slots sont pris et je peux pas changer ca ; la vraie problématique est que l'OOM ne semble pas solutionné par un "killterm" ou quelque chose pour tuer les process qui bouffent trop et redémarrer derrière sans salvage shutdown. Et je sais pas comment gérer ca..
pour le ntfs, malheureusement ya rien de particulier sur root, et les volumes ntfs sont démontés proprement, mais restent en lecture seule (sur plusieurs ordis lmde5) ; je me souviens également qu'un ntfs mal démonté ne se monte pas du tout, et bien démonté se monte en r/w, or là sous lmde c'est bien la première fois que je vois du read only..
je poursuis mes investigations..
[^] # Re: reponse D jean pierre
Posté par NeoX . Évalué à 3.
le OOM peut avoir besoin d'etre parametrer pour killer tes applis plus tot
maintenant la question, c'est quelles applis remplissent la RAM, et est-ce critique de les arreter sauvagement.
peut-etre verifier aussi tes barretes de ram en faisant un memtest depuis le boot du pc ou boot depuis une clef USB
[^] # Re: reponse D jean pierre
Posté par tkr . Évalué à 0.
hello
je te remercie de ta réponse
pour le ntfs à priori j'explorerai le web la réponse doit pas etre simple
pour le oom j'imaginais que comme openbsd le fait par défaut (à savoir, en cas d'OOM -expérimenté- dans les cinq minutes il kill tout le Xorg, et relance le bouzin juste après) linux debian, érigé en star linuxienne de la stabilité, ferait de meme, à savoir moins de 5/10min d'attente que les applis se resaississent avant de tuer les brebis galeuses dans l'idée de rendre à nouveau le système propre et suffisamment réactif avant redémarrage éventuel (en cas de freeze, clavier/souris sont totalement inopérants)
sauf que le 5/10min observé sous openbsd, sous linux l'oom c'est 72heures (!!) ce qui est à mon gout inacceptable à l'instar de l'observateur observé ci-dessous :
https://unix.stackexchange.com/questions/373312/oom-killer-doesnt-work-properly-leads-to-a-frozen-os
# Magic SysRq
Posté par Arthur Accroc . Évalué à 2. Dernière modification le 02 août 2022 à 03:36.
C’est possible avec les touches Magic SysRq.
Alt+Syst+f déclenche l’OOM-Killer… si c’est autorisé. Par contre, il faut espérer qu’il tue le « bon » processus !
L’autorisation dépend d’un paramètre noyau, à vérifier avec
sysctl. Le bit correspondant à 64 doit être activé danskernel.sysrq.Par exemple, supposons que sysctl te donne ça :
Tu prends une calculatrice permettant les opérations binaires, comme Speedcrunch ou calc, tu fais :
Si tu obtiens un nombre différent du précédent, il faut créer un fichier du genre
/etc/sysctl.d/99-sysrq.confavec pour contenu (toujours dans l’exemple) :Ça autorisera les touches Magic SysRq à intervenir sur les processus après le prochain démarrage (pour la session courante, la commande
sudo sysctl -w kernel.sysrq=244fera la même chose).« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Magic SysRq
Posté par tkr . Évalué à 0.
hello
je te remercie de ta réponse
je m'interrogeais :
* est il possible d'effectuer un script de cette procédure, de manière à "configurer" ca en une manip? (j'ai une quinzaine d'ordis sous cet os qui sont concernés)
* est il possible de faire l'OOMkill automatiquement? les utilisateurs n'étant pas forcément au jus des combinaisons de touche..
* y a t-il une calculette binaire disponible par défaut sur cette distri? ou réalisable via LO?
ayant encore été "concerné" par ce OOM dernièrement, c'est un peu mon espoir..
merci!
[^] # Re: Magic SysRq
Posté par tkr . Évalué à 0.
hello :)
déjà merci pour la longue réponse explicative
j'ai donc pris cet apm pour tester le principe du OOM killer
pour la caltos, j'ai trouvé cela :
https://www.rapidtables.com/calc/math/binary-calculator.html
en partant de l'exemple donné :
sysctl kernel.sysrq
qui donne
kernel.sysrq = 180
donc 180 à mettre dans l'exemple en premier chiffre, opération "or"(|) à mettre en second, et le résultat ("244) je le recopie dans :
sysctl -w kernel.sysrq=244
Ensuite redémarrer
J'ai noté que les touches sys/imprécran fonctionnent toutes les deux. Il faut faire des essais avant pour bien comprendre.
j'en suis arrivé à :
alt+printscreen+ (k ou f)
alt+(Fn/Syst)+(k ou f)
sachant que sur pc portable souvent les touches imprécran/syst sont différentes :o
si j'en déduis le wiki que :
k tue xorg
f les applis
par contre, ne pas oublier que le num activé ou désactivé sur les pc dénués de clavier tactile peut tout changer au jeu, et potentiellement "désactiver" les touches magiques..
je poursuis ma quete, étant parvenu à "terminer" un xorg en expérimentation d'OOM volontaire.. voir si en situation réelle cela fera pareil, pour éviter les 72+heures de grattage sans réponse..
merci!
[^] # Re: Magic SysRq
Posté par Arthur Accroc . Évalué à 2. Dernière modification le 05 octobre 2022 à 02:56.
sysctl ne change que la valeur courante, pas celle après redémarrage.
J’ai regardé sur une Ubuntu, le fichier qui règle la valeur à chaque démarrage est /etc/sysctl.d/10-magic-sysrq.conf . C’est peut-être le même sur Debian et donc LMDE.
Et tous les logiciels lancés dessous. Un peu radical !
Enfin normalement une à la fois (si d’autres n’en dépendent pas, comme ce serait le cas si c’était X.org ou l’environnement graphique qui était tué).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Magic SysRq
Posté par Arthur Accroc . Évalué à 2.
C’est possible (et plus facile à faire en Perl qu’en bash…), mais est-ce que ce serait vraiment intéressant ?
Tu gères une quinzaine d’ordinateurs sous ce système, veux‐tu vraiment qu’ils aient un réglage différent quant aux touches Magic SysRq autorisées ?
Sinon, autant déterminer la valeur qui te convient et copier le fichier qui la règle sur tous ces ordinateurs.
Il y a des logiciels pour ça (et qui ne nécessitent pas les Magic SysRq en général) :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.