Bizarrerie sous Sierra - plantage =c3=a0 l'ancienne et je suis vir=c3=a9 de ma session :)
52 réponses
none
Bonjour à tous,
Sur un iMAc 27 pouces fin 2013, sous Sierra, toutes MAJ faites y compris
la toute dernière MAJ de sécurité.
Périphériques connectés par un hub usb 3.0 : une imprimante epson, un
scanner LIDE. Rien de fracassant donc (et ils sont là depuis des lustres)/
Ce matin, et il y a un mois environ, un petit incident étrange, jamais
survenu sur les systèmes antérieurs - et j'en ai connu beaucoup :)
Je sors la machine de veille (elle a déjà fonctionné dans la journée
concernée, ce n'est pas le premier réveil), je lance Thunderbird à jour
(que j'utilise depuis des années) pour écrire un mail très banal. Au
bout de qques mots rédigés, la roue se met à tourner et plus rien. Un
plantage à l'ancienne (impossible par exemple de changer d'application
par pomme-tabulation). Comme un panic, mais sans le fameux message
occupant l'écran (qui a d’ailleurs peut-être disparu ?)
L'écran devient noir, et je suis ramené au tableau d'ouverture des
sessions - l'écran avec le logo des différents utilisateurs répertoriés.
Je tape alors mon mot de passe, ma session s'ouvre à nouveau sans
problème, et ça repart.
Rien de récent à signaler du type nouvelle installation.
Là c'est peut-être un peu exagéré :-) Il y a quand même des process qui consomment du CPU parce qu'ils sont censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-) je voulais dire : associer le relevé des process par formule ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1 (qui donne le process consommant le plus de cpu) à la condition >120, avant de killer. En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur plusieurs échantillons, alors un process peut momentanément atteindre ou très légèrement dépasser le seuil de 100% sans qu'il soit en train de partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process les plus gourmands faire plus de 100%. -- J. B.
pehache <pehache.7@gmail.com> wrote:
Là c'est peut-être un peu exagéré :-)
Il y a quand même des process qui consomment du CPU parce qu'ils sont
censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-)
je voulais dire : associer le relevé des process par formule
ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1
(qui donne le process consommant le plus de cpu)
à la condition >120, avant de killer.
En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur
plusieurs échantillons, alors un process peut momentanément atteindre ou
très légèrement dépasser le seuil de 100% sans qu'il soit en train de
partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process
les plus gourmands faire plus de 100%.
--
J. B.
Là c'est peut-être un peu exagéré :-) Il y a quand même des process qui consomment du CPU parce qu'ils sont censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-) je voulais dire : associer le relevé des process par formule ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1 (qui donne le process consommant le plus de cpu) à la condition >120, avant de killer. En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur plusieurs échantillons, alors un process peut momentanément atteindre ou très légèrement dépasser le seuil de 100% sans qu'il soit en train de partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process les plus gourmands faire plus de 100%. -- J. B.
josephb
Fleuger wrote:
Reste à savoir si ça pourra marcher quand ça bloque ;-)
Ça m'étonnerait :-/ En effet quand on réalise le truc, il y a au moins 30 secondes ou 1 minute que le zinzin est parti en vrille, alors le temps qu'on réagisse et lance le script, même depuis Menu Script, plus rien ne répondra. D'autant que ça génère des blocages en cascade : Pour mon cas, je m'en suis aperçu parce que voulant revenir au Finder, il ne répondait plus, j'ai donc insisté 2 ou trois fois (et les secondes passent pendant qu'on se gratte l'occiput…) ; puis j'ai levé les yeux vers la barre de menu et la j'ai vu que iStat montrait le diagramme de CPU complètement saturé. Cliquant desus il m'a affiché disnoted 397% en premier (je n'en croyais pas mes yeux), Finder 100%, Firefox à quelques % J'ai essayé de relancer le Finder, qui a bien quitté mais n'a jamais voulu se relancer (plus de Bureau !), et à partir de là plus rien n'a répondu, même iStatMenu, tout était figé. Ne restait plus qu'à ettiendre le Mac en force. Donc, si tu veux être averti à temps, moi, je verrais plutôt un applet tournant en tâche de fond et qui scanne l'utilisation CPU toutes les 30"environ. Ce n'est pas bien difficile à faire : il faut utiliser la commande "on idle" de applescript, avec un return réglé à 30", voire 15". Là soit on décide de s'en tenir à un simple avertissement, soit on achève le script par une commande do shell script "kill -9 PID_du_process_fautif" with administrator privileges. -- J. B.
Fleuger <g4fleurot@free.fr> wrote:
Reste à savoir si ça pourra marcher quand ça bloque ;-)
Ça m'étonnerait :-/
En effet quand on réalise le truc, il y a au moins 30 secondes ou 1
minute que le zinzin est parti en vrille, alors le temps qu'on réagisse
et lance le script, même depuis Menu Script, plus rien ne répondra.
D'autant que ça génère des blocages en cascade :
Pour mon cas, je m'en suis aperçu parce que voulant revenir au Finder,
il ne répondait plus, j'ai donc insisté 2 ou trois fois (et les secondes
passent pendant qu'on se gratte l'occiput…) ; puis j'ai levé les yeux
vers la barre de menu et la j'ai vu que iStat montrait le diagramme de
CPU complètement saturé.
Cliquant desus il m'a affiché
disnoted 397% en premier (je n'en croyais pas mes yeux), Finder 100%,
Firefox à quelques %
J'ai essayé de relancer le Finder, qui a bien quitté mais n'a jamais
voulu se relancer (plus de Bureau !), et à partir de là plus rien n'a
répondu, même iStatMenu, tout était figé.
Ne restait plus qu'à ettiendre le Mac en force.
Donc, si tu veux être averti à temps, moi, je verrais plutôt un applet
tournant en tâche de fond et qui scanne l'utilisation CPU toutes les
30"environ.
Ce n'est pas bien difficile à faire : il faut utiliser la commande "on
idle" de applescript, avec un return réglé à 30", voire 15".
Là soit on décide de s'en tenir à un simple avertissement,
soit on achève le script par une commande
do shell script "kill -9 PID_du_process_fautif" with administrator
privileges.
--
J. B.
Reste à savoir si ça pourra marcher quand ça bloque ;-)
Ça m'étonnerait :-/ En effet quand on réalise le truc, il y a au moins 30 secondes ou 1 minute que le zinzin est parti en vrille, alors le temps qu'on réagisse et lance le script, même depuis Menu Script, plus rien ne répondra. D'autant que ça génère des blocages en cascade : Pour mon cas, je m'en suis aperçu parce que voulant revenir au Finder, il ne répondait plus, j'ai donc insisté 2 ou trois fois (et les secondes passent pendant qu'on se gratte l'occiput…) ; puis j'ai levé les yeux vers la barre de menu et la j'ai vu que iStat montrait le diagramme de CPU complètement saturé. Cliquant desus il m'a affiché disnoted 397% en premier (je n'en croyais pas mes yeux), Finder 100%, Firefox à quelques % J'ai essayé de relancer le Finder, qui a bien quitté mais n'a jamais voulu se relancer (plus de Bureau !), et à partir de là plus rien n'a répondu, même iStatMenu, tout était figé. Ne restait plus qu'à ettiendre le Mac en force. Donc, si tu veux être averti à temps, moi, je verrais plutôt un applet tournant en tâche de fond et qui scanne l'utilisation CPU toutes les 30"environ. Ce n'est pas bien difficile à faire : il faut utiliser la commande "on idle" de applescript, avec un return réglé à 30", voire 15". Là soit on décide de s'en tenir à un simple avertissement, soit on achève le script par une commande do shell script "kill -9 PID_du_process_fautif" with administrator privileges. -- J. B.
josephb
Fleuger wrote:
Avec Cakebrew, c'est du gâteau d'installer une formule ;-)
Ah, faudra que je m'y intéresse. Merci. -- J. B.
Fleuger <g4fleurot@free.fr> wrote:
Avec Cakebrew, c'est du gâteau d'installer une formule ;-)
Avec Cakebrew, c'est du gâteau d'installer une formule ;-)
Ah, faudra que je m'y intéresse. Merci. -- J. B.
pehache
Le 12/12/2017 à 20:55, Joseph-B a écrit :
pehache wrote:
Là c'est peut-être un peu exagéré :-) Il y a quand même des process qui consomment du CPU parce qu'ils sont censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-) je voulais dire : associer le relevé des process par formule ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1 (qui donne le process consommant le plus de cpu) à la condition >120, avant de killer. En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur plusieurs échantillons, alors un process peut momentanément atteindre ou très légèrement dépasser le seuil de 100% sans qu'il soit en train de partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process les plus gourmands faire plus de 100%. 120 ou n'importe quoi d'autre n'est pas une condition suffisante pour
faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
Le 12/12/2017 à 20:55, Joseph-B a écrit :
pehache <pehache.7@gmail.com> wrote:
Là c'est peut-être un peu exagéré :-)
Il y a quand même des process qui consomment du CPU parce qu'ils sont
censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-)
je voulais dire : associer le relevé des process par formule
ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1
(qui donne le process consommant le plus de cpu)
à la condition >120, avant de killer.
En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur
plusieurs échantillons, alors un process peut momentanément atteindre ou
très légèrement dépasser le seuil de 100% sans qu'il soit en train de
partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process
les plus gourmands faire plus de 100%.
120 ou n'importe quoi d'autre n'est pas une condition suffisante pour
faire un kill automatique. De nombreux softs peuvent utiliser plusieurs
coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait
normale (encodage video par exemple).
Là c'est peut-être un peu exagéré :-) Il y a quand même des process qui consomment du CPU parce qu'ils sont censé le faire ! C'est insuffisant comme critère pour les les dégommer.
Non, tu ne m'as pas compris :-) je voulais dire : associer le relevé des process par formule ps -Acr -o 'user,pid,%cpu,comm'| head -2 | tail -1 (qui donne le process consommant le plus de cpu) à la condition >120, avant de killer. En effet, le calcul de pcpu (ou %cpu) est une somme pondérée sur plusieurs échantillons, alors un process peut momentanément atteindre ou très légèrement dépasser le seuil de 100% sans qu'il soit en train de partir en vrille pour autant, et la somme des %cpu des 3 ou 4 process les plus gourmands faire plus de 100%. 120 ou n'importe quoi d'autre n'est pas une condition suffisante pour
faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
josephb
pehache wrote:
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure solution. Mais on peut envisager de présenter la possibilité à l'utilisateur ? -- J. B.
pehache <pehache.7@gmail.com> wrote:
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour
faire un kill automatique. De nombreux softs peuvent utiliser plusieurs
coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait
normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure
solution.
Mais on peut envisager de présenter la possibilité à l'utilisateur ?
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure solution. Mais on peut envisager de présenter la possibilité à l'utilisateur ? -- J. B.
pehache
Le 12/12/2017 à 08:41, pehache a écrit :
Le 11/12/2017 à 14:42, Joseph-B a écrit :
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
Le 12/12/2017 à 08:41, pehache a écrit :
Le 11/12/2017 à 14:42, Joseph-B a écrit :
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet...
A tout hasard j'ai le script en question (il faut le script, et un
fichier *.plist pour le lancer à intervalles réguliers).
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
derfnam
pehache wrote:
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
J'aime bien le nom que tu as donné à ce script ;-) -- Manfred Middle Of Nowhere iMac Intel Core 2 Duo, early 2009, OS X 10.11.6 "I would trade all my technology for an afternoon with Socrates."(S.J.)
pehache <pehache.7@gmail.com> wrote:
>> Certains utilisateurs geek confrontés régulièrement à cette chienlit
>
> C'est le mot en effet...
>
> A tout hasard j'ai le script en question (il faut le script, et un
> fichier *.plist pour le lancer à intervalles réguliers).
J'aime bien le nom que tu as donné à ce script ;-)
--
Manfred
Middle Of Nowhere
iMac Intel Core 2 Duo, early 2009, OS X 10.11.6
"I would trade all my technology for an afternoon with Socrates."(S.J.)
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
J'aime bien le nom que tu as donné à ce script ;-) -- Manfred Middle Of Nowhere iMac Intel Core 2 Duo, early 2009, OS X 10.11.6 "I would trade all my technology for an afternoon with Socrates."(S.J.)
pehache
Le 12/12/2017 à 22:54, Manfred La Cassagnère a écrit :
pehache wrote:
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
J'aime bien le nom que tu as donné à ce script ;-)
;-)
Le 12/12/2017 à 22:54, Manfred La Cassagnère a écrit :
pehache <pehache.7@gmail.com> wrote:
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet...
A tout hasard j'ai le script en question (il faut le script, et un
fichier *.plist pour le lancer à intervalles réguliers).
Le 12/12/2017 à 22:54, Manfred La Cassagnère a écrit :
pehache wrote:
Certains utilisateurs geek confrontés régulièrement à cette chienlit
C'est le mot en effet... A tout hasard j'ai le script en question (il faut le script, et un fichier *.plist pour le lancer à intervalles réguliers).
Le tout zippé. https://drive.google.com/file/d/1QEmp5YGPtYxQvodVOppX2bxe2PpxCMI_/view Télécharger, dézippper, et lire le README
J'aime bien le nom que tu as donné à ce script ;-)
;-)
pehache
Le 12/12/2017 à 21:49, Joseph-B a écrit :
pehache wrote:
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure solution. Mais on peut envisager de présenter la possibilité à l'utilisateur ?
Oui, sans doute avec un Apple Script bien senti. Mais l'intérêt du script automatique limité aux process fautifs connus est néanmoins qu'il va s'exécuter même quand l'interface graphique ne répond plus. Depuis que je l'ai mis en place je n'ai plus été embêté par les vilains démons :-)
Le 12/12/2017 à 21:49, Joseph-B a écrit :
pehache <pehache.7@gmail.com> wrote:
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour
faire un kill automatique. De nombreux softs peuvent utiliser plusieurs
coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait
normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure
solution.
Mais on peut envisager de présenter la possibilité à l'utilisateur ?
Oui, sans doute avec un Apple Script bien senti. Mais l'intérêt du
script automatique limité aux process fautifs connus est néanmoins qu'il
va s'exécuter même quand l'interface graphique ne répond plus. Depuis
que je l'ai mis en place je n'ai plus été embêté par les vilains démons :-)
">120 ou n'importe quoi d'autre n'est pas une condition suffisante pour faire un kill automatique. De nombreux softs peuvent utiliser plusieurs coeurs et dépasser 100% pendant plusieurs minutes de façon tout à fait normale (encodage video par exemple).
En effet, un kill bête et méchant n'est peut-être pas la meilleure solution. Mais on peut envisager de présenter la possibilité à l'utilisateur ?
Oui, sans doute avec un Apple Script bien senti. Mais l'intérêt du script automatique limité aux process fautifs connus est néanmoins qu'il va s'exécuter même quand l'interface graphique ne répond plus. Depuis que je l'ai mis en place je n'ai plus été embêté par les vilains démons :-)
Le Moustique
Le 13/12/2017 à 08:25, pehache a écrit :
Mais l'intérêt du script automatique limité aux process fautifs connus est néanmoins qu'il va s'exécuter même quand l'interface graphique ne répond plus. Depuis que je l'ai mis en place je n'ai plus été embêté par les vilains démons :-)
Tu aurais pu l'appeler "L'Exorciste"... ;-) -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
Le 13/12/2017 à 08:25, pehache a écrit :
Mais l'intérêt du script automatique limité aux process fautifs connus
est néanmoins qu'il va s'exécuter même quand l'interface graphique ne
répond plus. Depuis que je l'ai mis en place je n'ai plus été embêté par
les vilains démons :-)
Tu aurais pu l'appeler "L'Exorciste"... ;-)
--
/)
-:oo= Guillaume
)
Je nettoyais mon clavier, et le coup est parti tout seul.
Mais l'intérêt du script automatique limité aux process fautifs connus est néanmoins qu'il va s'exécuter même quand l'interface graphique ne répond plus. Depuis que je l'ai mis en place je n'ai plus été embêté par les vilains démons :-)
Tu aurais pu l'appeler "L'Exorciste"... ;-) -- /) -:oo= Guillaume ) Je nettoyais mon clavier, et le coup est parti tout seul.
