Bizarrerie sous Sierra - plantage =c3=a0 l'ancienne et je suis vir=c3=a9 de ma session :)

Le
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.

Des idées ? Merci et bonne journée !
Vos réponses Page 1 / 6
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
josephb
Le #26455472
Des idées ? Merci et bonne journée !

Ce qui aurait été intéressant est que vous ayez eu le réflexe de lancer
(très vite !) le Moniteur d'Activité pour repérer le process qui
bouffait soudain toute la CPU.
De l'expérience que j'ai vécue ces jours-ci (je viens de migrer à El
Cap) et recherches que j'ai menées :
J'ai ma petite idée que vous auriez vu le process "distnoted", lancé par
le User "_spotlight" flirter avec les 300% (sic) d'usage processeur.
Ce bug aléatoire est connu depuis Mavericks et est très probablement
généré par un téléscopage de commandes Système entre le couple Time
Machine - Spotlight (cherchant à lancer son indexation) et une autre
application.
Cela donne en effet toutes les apparences d'un Panic Kernel, sauf que
dans le cas présent il n'y a pas de violation de mémoire protégée qui
déclencherait un PK dès son apparition ; ici le Système est tout
bonnement etouffé et ne peut ni signaler l'incident, ni tuer le process
fautif.
Le redémarage de la session, ou du Mac remet les choses en route.
Certains utilisateurs geek confrontés régulièrement à cette chienlit ont
imaginé des scripts destinés à tuer le process distnoted incriminé.
En fait, il existe généralement 3 process "distnoted" enfants issus de 3
process parent différents :
"_disnote" (un deamon : ne pas toucher !!)
<utilisateur de la session>
"_spotlight"
tournant dans OS X, ce qui ne simplifie pas la tâche.
La bonne question à se poser est de savoir si Apple a ENFIN introduit
une détection préventive de ce phénomène, très aléatoire et improbable,
dans High Sierra ?
Pour en savoir plus, lancer une recherche web avec :
distnoted process CPU runaway
Voilà ce que j'en sais, c'est à dire pas grand chose d'utile.
--
J. B.
none
Le #26455556
Le 11/12/2017 à 14:42, Joseph-B a écrit :
(...)
Ce qui aurait été intéressant est que vous ayez eu le réflexe de lancer
(très vite !) le Moniteur d'Activité pour repérer le process qui
bouffait soudain toute la CPU.

Merci. Malheureusement je n'ai pas eu la présence d'esprit d'aller voir
de ce côté ci.
De l'expérience que j'ai vécue ces jours-ci (je viens de migrer à El
Cap) et recherches que j'ai menées :
J'ai ma petite idée que vous auriez vu le process "distnoted", lancé par
le User "_spotlight" flirter avec les 300% (sic) d'usage processeur.
Ce bug aléatoire est connu depuis Mavericks et est très probablement
généré par un téléscopage de commandes Système entre le couple Time
Machine - Spotlight (cherchant à lancer son indexation) et une autre
application.

Time Machine n'était pas en fonctionnement à ce moment-là - mais cela ne
signifie peut-être pas qu'il est totalement inactif dans les couches
profondes du système (?)(...)
La bonne question à se poser est de savoir si Apple a ENFIN introduit
une détection préventive de ce phénomène, très aléatoire et improbable,
dans High Sierra ?
Pour en savoir plus, lancer une recherche web avec :
distnoted process CPU runaway
Voilà ce que j'en sais, c'est à dire pas grand chose d'utile.


Entendu. Merci encore !
pehache
Le #26455560
Le 11/12/2017 à 11:03, a écrit :
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.
Des idées ? Merci et bonne journée !


Essayer de voir dans l'appli console.app s'il y a des messages d'erreurs
au moment du plantage.
pehache
Le #26455559
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).
josephb
Le #26455575
Merci. Malheureusement je n'ai pas eu la présence d'esprit d'aller voir
de ce côté ci.

Quand on y est confronté pour la première fois c'est tellement
déstabilisant que l'on a pas forcément le bon réflexe.
C'est bien parce que j'avais iStat Menus installé que j'ai pu identifier
la cause de ce plantage que je n'avais /jamais connu sous OS X/.
--
J. B.
josephb
Le #26455576
pehache
A tout hasard j'ai le script en question (il faut le script, et un
fichier *.plist pour le lancer à intervalles réguliers).

Si l'ensemble est prêt à tourner ça peut intéresser certains, parce que
l'installation via homebrew ça va en rebuter plus d'un.
Cela dit, je me demandais pourquoi faire ce script orienté spécialement
"distnoted", alors que parfois d'autres process (buggés) pourraient être
amenés à faire péter le CPU ;
une commande qui ciblerait toute excursion hors limites du CPU serait
peut-être plus intéressante finalement.
Par exemple, cette commande liste les 3 process à l'instant les plus
gros consommateurs de CPU, avec juste les renseignements indispensables
ps -Acr -o 'user,pid,%cpu,comm'| head -4
--
J. B.
none
Le #26455577
Le 12/12/2017 à 08:38, pehache a écrit :
(...)
Essayer de voir dans l'appli console.app s'il y a des messages d'erreurs
au moment du plantage.

Bonjour,
A priori il me semble qu'il y a deux messages (dans console>rapports
système>colonne erreurs et pannes) :
1) un fichier nommé
thunderbird_2017-12-11-095451_iMac-de-Marc.wakeups_resource.diag
2) un autre nommé
WindowServer_2017-12-11-095511_iMac-de-Marc.crash
J'envoie les premières lignes - et peux aussi envoyer la suite si
nécessaire (?)
------------
Voici les premières lignes du premier (pas très long) :
Date/Time: 2017-12-11 09:52:49.790612 +0100
OS Version: Mac OS X 10.12.6 (Build 16G1114)
Architecture: x86_64
Report Version: 19
Command: thunderbird
Path: /Applications/Thunderbird.app/Contents/MacOS/thunderbird
Version: 52.5.0 (52.5.0)
Parent: launchd [1]
PID: 3417
Event: wakeups
Wakeups: 46552 wakeups over the last 120 seconds (388 wakeups
per second average), exceeding limit of 150 wakeups per second over 300
seconds
Duration: 119.88s
Steps: 73
Hardware model: iMac14,2
Active cpus: 4
Fan speed: 1199 rpm
---------------
Et celles du deuxième (beaucoup plus long !) :
Process: WindowServer [149]
Path:
/System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier: WindowServer
Version: 600.00 (15)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Responsible: WindowServer [149]
User ID: 88
Date/Time: 2017-12-11 09:55:02.734 +0100
OS Version: Mac OS X 10.12.6 (16G1114)
Report Version: 12
Anonymous UUID: 8F29B5DF-D555-EBC4-F1B7-C3FCD2AA14EE
Sleep/Wake UUID: E45E324A-4CE2-4F30-AA0B-4BD193DDCE78
Time Awake Since Boot: 50000 seconds
Time Since Wake: 140 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
Assertion failed: (false && "10 seconds of continuous GPU Driver
unreadiness, relaunching WindowServer"), function void
IMGGraphicsStackReadinessFailure(), file Server/Windows/Updater.cc, line
2864.
pehache
Le #26455590
Le 12/12/2017 à 12:24, Joseph-B a écrit :
pehache
A tout hasard j'ai le script en question (il faut le script, et un
fichier *.plist pour le lancer à intervalles réguliers).

Si l'ensemble est prêt à tourner ça peut intéresser certains, parce que
l'installation via homebrew ça va en rebuter plus d'un.

Prêt à tourner, oui et non. Il faut quand même copier à la main 2
fichiers dans les dossiers système, en en ayant éventuellement modifié
un avant.
Cela dit, je me demandais pourquoi faire ce script orienté spécialement
"distnoted", alors que parfois d'autres process (buggés) pourraient être
amenés à faire péter le CPU ;

Exact. J'avais d'ailleurs adapté le script pour qu'il abatte aussi en vol
le process "powerd", qui avait tendance à s'emballer parfois aussi sur mon
Mac.
une commande qui ciblerait toute excursion hors limites du CPU serait
peut-être plus intéressante finalement.
Par exemple, cette commande liste les 3 process à l'instant les plus
gros consommateurs de CPU, avec juste les renseignements indispensables
ps -Acr -o 'user,pid,%cpu,comm'| head -4

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.
g4fleurot
Le #26455594
Joseph-B a bien voulu nous faire partager ses réflexions sur ce
passionnant sujet :
ps -Acr -o 'user,pid,%cpu,comm'| head -4

Super !
J'ai mis dans le menu des sripts :
set f to do shell script "ps -Acr -o 'user,pid,%cpu,comm'| head -5"
set the clipboard to (f as text)
display dialog (f as text) buttons "OK"
Reste à savoir si ça pourra marcher quand ça bloque ;-)
--
Veuillez ioniser la rétro-signature holographique avant de
poly-fracasser sciemment.
Gérard FLEUROT
g4fleurot
Le #26455599
Joseph-B estime devoir nous faire part de ceci :
Si l'ensemble est prêt à tourner ça peut intéresser certains, parce que
l'installation via homebrew ça va en rebuter plus d'un.

Avec Cakebrew, c'est du gâteau d'installer une formule ;-)
--
Gérard FLEUROT
Publicité
Poster une réponse
Anonyme