Sur mon iMac 2011 j'ai des plantages réguliers dans OS X, qui il me
semble ont commencé après la MAJ 10.11.4.
La session se fige complètement, avec la roue multicolore, impossible de
rien faire... Il faut soit éteindre le Mac avec le bouton on/off, soit
tuer la session en se connectant en SSH (ce qui montre que c'est juste
la session qui est bloquée, pas tout l'OS).
D'autres ont le même genre de problème ?
--
"les supports évoluant tellement vite, je ne sais
pas ce que c'est qu'une "carte SD"" (FLC)
In article <1mll2dn.1nc23mh1o1yv7eN%, (Fleuger) wrote:
La faute à Nyquist et son fameux critère lorsque la courbe passe par -1
Tu peux expliquer ça ?
-- Jean-Pierre
g4fleurot
pehache wrote:
http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
-- Gérard FLEUROT plus un
pehache <pehache.7@gmail.com> wrote:
http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic
droit sur la barre d'onglets) qui permet d'identifier le "propriétaire"
du processus
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
-- Gérard FLEUROT plus un
g4fleurot
J.P wrote:
In article <1mll2dn.1nc23mh1o1yv7eN%, (Fleuger) wrote:
> La faute à Nyquist et son fameux critère lorsque la courbe passe par -1
Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses : <https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques quand j'ai fait un stage d'électronique en 1966 Si la courbe passe par -1 le système entre en résonance et et l'emballement peut détruire les jonctions des transistors.
-- Gérard FLEUROT plus un
J.P <jpp@gmail.com> wrote:
In article <1mll2dn.1nc23mh1o1yv7eN%g4fleurot@free.fr>,
g4fleurot@free.fr (Fleuger) wrote:
> La faute à Nyquist et son fameux critère lorsque la courbe passe par -1
Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses :
<https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques
quand j'ai fait un stage d'électronique en 1966
Si la courbe passe par -1 le système entre en résonance et et
l'emballement peut détruire les jonctions des transistors.
In article <1mll2dn.1nc23mh1o1yv7eN%, (Fleuger) wrote:
> La faute à Nyquist et son fameux critère lorsque la courbe passe par -1
Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses : <https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques quand j'ai fait un stage d'électronique en 1966 Si la courbe passe par -1 le système entre en résonance et et l'emballement peut détruire les jonctions des transistors.
-- Gérard FLEUROT plus un
J.P
In article <1mllpqo.2qe5t51cej1gjN%, (Fleuger) wrote:
J.P wrote:
> In article <1mll2dn.1nc23mh1o1yv7eN%, > (Fleuger) wrote: > > > La faute à Nyquist et son fameux critère lorsque la courbe passe par -1 > > Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses : <https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques quand j'ai fait un stage d'électronique en 1966 Si la courbe passe par -1 le système entre en résonance et et l'emballement peut détruire les jonctions des transistors.
Ah oui ! c'est le truc qui permet de calculer quand ça va fumer . Sauf que, d'expérience, ça fumait souvent avant ce que les calculs avaient prévu vu la dispersion des tolérances sur les composants :-) Mon premier ampli, j'avais tout calculé: n'a jamais marché !
-- Jean-Pierre
In article <1mllpqo.2qe5t51cej1gjN%g4fleurot@free.fr>,
g4fleurot@free.fr (Fleuger) wrote:
J.P <jpp@gmail.com> wrote:
> In article <1mll2dn.1nc23mh1o1yv7eN%g4fleurot@free.fr>,
> g4fleurot@free.fr (Fleuger) wrote:
>
> > La faute à Nyquist et son fameux critère lorsque la courbe passe par -1
>
> Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses :
<https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques
quand j'ai fait un stage d'électronique en 1966
Si la courbe passe par -1 le système entre en résonance et et
l'emballement peut détruire les jonctions des transistors.
Ah oui ! c'est le truc qui permet de calculer quand ça va fumer .
Sauf que, d'expérience, ça fumait souvent avant ce que les calculs
avaient prévu vu la dispersion des tolérances sur les composants :-)
Mon premier ampli, j'avais tout calculé: n'a jamais marché !
In article <1mllpqo.2qe5t51cej1gjN%, (Fleuger) wrote:
J.P wrote:
> In article <1mll2dn.1nc23mh1o1yv7eN%, > (Fleuger) wrote: > > > La faute à Nyquist et son fameux critère lorsque la courbe passe par -1 > > Tu peux expliquer ça ?
C'était une boutade. Un peu trop compliqué pour moi :-(
Mais tu trouveras certainement une explication parmi ces réponses : <https://www.google.fr/?gws_rd=ssl#safe=off&q=critère+de+nyquist>
C'est comme ça qu'on expliquait la stabilité des systèmes éléctroniques quand j'ai fait un stage d'électronique en 1966 Si la courbe passe par -1 le système entre en résonance et et l'emballement peut détruire les jonctions des transistors.
Ah oui ! c'est le truc qui permet de calculer quand ça va fumer . Sauf que, d'expérience, ça fumait souvent avant ce que les calculs avaient prévu vu la dispersion des tolérances sur les composants :-) Mon premier ampli, j'avais tout calculé: n'a jamais marché !
-- Jean-Pierre
J.P
In article <1mllqc9.1apkcjz1ozkkosN%, (Fleuger) wrote:
pehache wrote:
> http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
Oui, ça c'est utile ! c'est comme ça que je me suis aperçu qu'un compte encore actif me mangeait plein de CPU et de RAM avec Firefox, Mail et compagnie ...
-- Jean-Pierre
In article <1mllqc9.1apkcjz1ozkkosN%g4fleurot@free.fr>,
g4fleurot@free.fr (Fleuger) wrote:
pehache <pehache.7@gmail.com> wrote:
> http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic
droit sur la barre d'onglets) qui permet d'identifier le "propriétaire"
du processus
Oui, ça c'est utile ! c'est comme ça que je me suis aperçu qu'un compte
encore actif me mangeait plein de CPU et de RAM avec Firefox, Mail et
compagnie ...
In article <1mllqc9.1apkcjz1ozkkosN%, (Fleuger) wrote:
pehache wrote:
> http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
Oui, ça c'est utile ! c'est comme ça que je me suis aperçu qu'un compte encore actif me mangeait plein de CPU et de RAM avec Firefox, Mail et compagnie ...
-- Jean-Pierre
pehache
Le 12/04/2016 à 16:47, Fleuger a écrit :
pehache wrote:
http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
Elle y est, mais (volontairement) en dehors de la zone capturée
Le 12/04/2016 à 16:47, Fleuger a écrit :
pehache <pehache.7@gmail.com> wrote:
http://prntscr.com/ar31z3
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic
droit sur la barre d'onglets) qui permet d'identifier le "propriétaire"
du processus
Elle y est, mais (volontairement) en dehors de la zone capturée
Par rapport à ta présentation, j'ai ajouté la colonne Utilisateur (clic droit sur la barre d'onglets) qui permet d'identifier le "propriétaire" du processus
Elle y est, mais (volontairement) en dehors de la zone capturée
voir_le_reply-to
DV wrote:
En tout cas, RapidWeaver est cité dans les deux listes. Une piste à creuser pour Gérald ?
C'est un peu normal qu'il soit cité : il intervient forcément pour la prévisualisation. Je patiente.
Un truc bizarre quand même : je n'ai pas envoyé de rapport à Apple pour la bonne raison que le mac n'est pas exactement planté et ne détecte donc pas d'anomalie. Juste accaparé par un process dont on ne peut sortir qu'en attendant ou en forçant le redémarrage (qui devrait donner lieu à rapport, mais non !).
-- Gérald
DV <dv@nullepart.invalid> wrote:
En tout cas, RapidWeaver est cité dans les deux listes. Une piste à
creuser pour Gérald ?
C'est un peu normal qu'il soit cité : il intervient forcément pour la
prévisualisation. Je patiente.
Un truc bizarre quand même : je n'ai pas envoyé de rapport à Apple pour
la bonne raison que le mac n'est pas exactement planté et ne détecte
donc pas d'anomalie. Juste accaparé par un process dont on ne peut
sortir qu'en attendant ou en forçant le redémarrage (qui devrait donner
lieu à rapport, mais non !).
En tout cas, RapidWeaver est cité dans les deux listes. Une piste à creuser pour Gérald ?
C'est un peu normal qu'il soit cité : il intervient forcément pour la prévisualisation. Je patiente.
Un truc bizarre quand même : je n'ai pas envoyé de rapport à Apple pour la bonne raison que le mac n'est pas exactement planté et ne détecte donc pas d'anomalie. Juste accaparé par un process dont on ne peut sortir qu'en attendant ou en forçant le redémarrage (qui devrait donner lieu à rapport, mais non !).
-- Gérald
pehache
Le 05/04/2016 à 14:35, pehache a écrit :
Bonjour, Sur mon iMac 2011 j'ai des plantages réguliers dans OS X, qui il me semble ont commencé après la MAJ 10.11.4. La session se fige complètement, avec la roue multicolore, impossible de rien faire... Il faut soit éteindre le Mac avec le bouton on/off, soit tuer la session en se connectant en SSH (ce qui montre que c'est juste la session qui est bloquée, pas tout l'OS). D'autres ont le même genre de problème ?
Pour info, et vu que Manfred en reparle sur fcsa, j'ai fini par trouver une solution pour traiter le symptôme (le bug étant toujours présent), ici : http://apple.stackexchange.com/questions/111197/runaway-distnoted-process C'est un script qui contient une commande qui vérifie si le démon "distnoted" s'emballe (>100%) et le tue le cas échéant. Il suffit lancer ce script toutes les minutes par launchd. Je l'ai modifié un peu pour qu'il fasse la même chose avec le démon "powerd", et qu'il puisse les tuer quel que soit l'utilisateur connecté. Voilà le script, à placer par exemple dans /usr/local/bin : ============================================ #!/bin/sh # # check for runaway distnoted, kill if necessary # # found on : http://apple.stackexchange.com/questions/111197/runaway-distnoted-process # adapted to kill the process whatever the owner, and for powerd as well PATH=/bin:/usr/bin export PATH ps -reo '%cpu,uid,pid,command' | awk -v UID=$UID ' /distnoted agent$/ && $1 > 100 { system("kill -9 " $3) } ' ps -reo '%cpu,uid,pid,command' | awk -v UID=$UID ' /powerd$/ && $1 > 30 { system("kill -9 " $3) } ' ============================================ et le fichier plist à placer dans /Library/LaunchDaemons/ (killcrazydaemons.sh est le nom du fichier script ci-dessus) ============================================ <plist version="1.0"> <dict> <key>Label</key> <string>org.moi.killcrazydaemons</string> <key>Program</key> <string>/usr/local/bin/killcrazydaemons.sh</string> <key>StartInterval</key> <integer>60</integer> <!-- every minute --> </dict> </plist> =============================================
Le 05/04/2016 à 14:35, pehache a écrit :
Bonjour,
Sur mon iMac 2011 j'ai des plantages réguliers dans OS X, qui il me
semble ont commencé après la MAJ 10.11.4.
La session se fige complètement, avec la roue multicolore, impossible de
rien faire... Il faut soit éteindre le Mac avec le bouton on/off, soit
tuer la session en se connectant en SSH (ce qui montre que c'est juste
la session qui est bloquée, pas tout l'OS).
D'autres ont le même genre de problème ?
Pour info, et vu que Manfred en reparle sur fcsa, j'ai fini par trouver
une solution pour traiter le symptôme (le bug étant toujours présent),
ici :
C'est un script qui contient une commande qui vérifie si le démon
"distnoted" s'emballe (>100%) et le tue le cas échéant. Il suffit lancer
ce script toutes les minutes par launchd.
Je l'ai modifié un peu pour qu'il fasse la même chose avec le démon
"powerd", et qu'il puisse les tuer quel que soit l'utilisateur connecté.
Voilà le script, à placer par exemple dans /usr/local/bin :
============================================ #!/bin/sh
#
# check for runaway distnoted, kill if necessary
#
# found on :
http://apple.stackexchange.com/questions/111197/runaway-distnoted-process
# adapted to kill the process whatever the owner, and for powerd as well
ps -reo '%cpu,uid,pid,command' |
awk -v UID=$UID '
/powerd$/ && $1 > 30 {
system("kill -9 " $3)
}
'
============================================
et le fichier plist à placer dans /Library/LaunchDaemons/
(killcrazydaemons.sh est le nom du fichier script ci-dessus)
Bonjour, Sur mon iMac 2011 j'ai des plantages réguliers dans OS X, qui il me semble ont commencé après la MAJ 10.11.4. La session se fige complètement, avec la roue multicolore, impossible de rien faire... Il faut soit éteindre le Mac avec le bouton on/off, soit tuer la session en se connectant en SSH (ce qui montre que c'est juste la session qui est bloquée, pas tout l'OS). D'autres ont le même genre de problème ?
Pour info, et vu que Manfred en reparle sur fcsa, j'ai fini par trouver une solution pour traiter le symptôme (le bug étant toujours présent), ici : http://apple.stackexchange.com/questions/111197/runaway-distnoted-process C'est un script qui contient une commande qui vérifie si le démon "distnoted" s'emballe (>100%) et le tue le cas échéant. Il suffit lancer ce script toutes les minutes par launchd. Je l'ai modifié un peu pour qu'il fasse la même chose avec le démon "powerd", et qu'il puisse les tuer quel que soit l'utilisateur connecté. Voilà le script, à placer par exemple dans /usr/local/bin : ============================================ #!/bin/sh # # check for runaway distnoted, kill if necessary # # found on : http://apple.stackexchange.com/questions/111197/runaway-distnoted-process # adapted to kill the process whatever the owner, and for powerd as well PATH=/bin:/usr/bin export PATH ps -reo '%cpu,uid,pid,command' | awk -v UID=$UID ' /distnoted agent$/ && $1 > 100 { system("kill -9 " $3) } ' ps -reo '%cpu,uid,pid,command' | awk -v UID=$UID ' /powerd$/ && $1 > 30 { system("kill -9 " $3) } ' ============================================ et le fichier plist à placer dans /Library/LaunchDaemons/ (killcrazydaemons.sh est le nom du fichier script ci-dessus) ============================================ <plist version="1.0"> <dict> <key>Label</key> <string>org.moi.killcrazydaemons</string> <key>Program</key> <string>/usr/local/bin/killcrazydaemons.sh</string> <key>StartInterval</key> <integer>60</integer> <!-- every minute --> </dict> </plist> =============================================
mv
pehache a soumis à notre sagacité :
fcsa
fcsa ??? Caisse ? fr.comp.sys.amiga ou fr.com.sys.atari ? Cordialement. -- Michel Vauquois <http://michelvauquois.free-h.fr> 83 nuances d'automne : <http://matiere-a-voir-2.michelvauquois.free-h.fr>
pehache <pehache.7@gmail.com> a soumis à notre sagacité :
fcsa
fcsa ??? Caisse ? fr.comp.sys.amiga ou fr.com.sys.atari ?
Cordialement.
--
Michel Vauquois
<http://michelvauquois.free-h.fr>
83 nuances d'automne :
<http://matiere-a-voir-2.michelvauquois.free-h.fr>
