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.
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@nowhere.com> wrote:
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.
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 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 !
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.
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 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.
Le 11/12/2017 à 11:03, none@nowhere.com 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.
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 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 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).
josephb
wrote:
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.
<none@nowhere.com> wrote:
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/.
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
pehache wrote:
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.
pehache <pehache.7@gmail.com> wrote:
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
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 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.
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
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
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
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 12/12/2017 à 12:24, Joseph-B a écrit :
pehache wrote:
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.
Le 12/12/2017 à 12:24, Joseph-B a écrit :
pehache <pehache.7@gmail.com> wrote:
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.
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
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
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
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
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 plus un
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 ;-)
