10.13 High Sierra OS X Espace disque
- Créateur du sujet clement2312
- Date de début
M
Membre supprimé 1060554
Invité
Le SIP étant activé > le répertoire de la Bibliothèque du Système est verrouillé (même pour une intervention en root).
Il faut donc que tu désactives le SIP avant d'agir dans le dossier /System/Library/UserEventPlugins.
Pour cela > re-démarre en mode Recovery les 2 touches ⌘R pressées > va à la barre de menus supérieure de l'écran > menu : Utilitaires > lance le Terminal.
Dans la fenêtre ouverte > passe la commande :
Dans le «Terminal» de ta session > passe alors la commande :
=> re-démarre encore une fois > et vérifie si le processus UserEventPlugins s'emballe toujours.
Il faut donc que tu désactives le SIP avant d'agir dans le dossier /System/Library/UserEventPlugins.
Pour cela > re-démarre en mode Recovery les 2 touches ⌘R pressées > va à la barre de menus supérieure de l'écran > menu : Utilitaires > lance le Terminal.
Dans la fenêtre ouverte > passe la commande :
Bloc de code:
csrutil disable- et redémarre normalement pour ré-ouvrir ta session. Ce n'est que dans le Terminal de la Recovery qu'on peut désactiver le SIP.
Dans le «Terminal» de ta session > passe alors la commande :
Bloc de code:
sudo mv /System/Library/UserEventPlugins/AppleHIDMouseAgent.plugin /System/Library/UserEventPlugins/AppleHIDMouseAgent.plugin_orig- qui renomme le plugin AppleHIDMouseAgent.plugin --> AppleHIDMouseAgent.plugin_orig et par là le met en quarantaine.
=> re-démarre encore une fois > et vérifie si le processus UserEventPlugins s'emballe toujours.
M
Membre supprimé 1060554
Invité
Alors passe déjà la commande de réversion :
Et voici un test un peu radical (je viens de l'exécuter sur mon Mac > et re-démarré sans problème --> je ne voulais pas te l'infliger en aveugle) --> tu passes la commande :
=> re-démarre encore une fois et dis ce qu'il en est du processus UserEventPlugins.
Bloc de code:
sudo mv /System/Library/UserEventPlugins/AppleHIDMouseAgent.plugin_orig /System/Library/UserEventPlugins/AppleHIDMouseAgent.plugin- qui renomme le plugin comme au départ
Et voici un test un peu radical (je viens de l'exécuter sur mon Mac > et re-démarré sans problème --> je ne voulais pas te l'infliger en aveugle) --> tu passes la commande :
Bloc de code:
sudo mv /System/Library/UserEventPlugins /System/Library/UserEventPlugins_orig- qui renomme le dossier UserEventPlugins --> UserEventPlugins_orig et par là le met en quarantaine
=> re-démarre encore une fois et dis ce qu'il en est du processus UserEventPlugins.
M
Membre supprimé 1060554
Invité
J'ai découvert comme toi le processus UserEventPlugins qui m'a l'air d'un service dans le Système qui gère des plugins secondaires orientés utilisateur à la place du Serveur maître launchd. Donc logiquement le dossier /System/Library/UserEventPlugins est le répertoire spécialisé contenant la collection des plugins dont s'occupe ce service.
Je pense que le test que tu viens de faire apporte la preuve suivante : c'est un des plugins de la collection contenue dans le dossier UserEventPlugins qui suscite l'emballage du service > vraisemblablement en relation avec un appareillage que tu as ajouté au Mac > puisque mettre en quarantaine le dossier complet fait cesser l'emballage.
Mais tu admettras sans mal que verrouiller le dossier complet n'est pas une solution "chirugicale" mais au contraire massive et non satisfaisante. Il conviendra donc de conduire de petites expérimentations sur les plugins de ce dossier > jusqu'à déceler lequel emballe le processus du service. En connaissant son nom > on pourra deviner sa fonction > et par là remonter la piste jusqu'à l'appareil géré.
Comme je ne suis pas du soir > je te propose de remettre cette tâche à demain.
Je pense que le test que tu viens de faire apporte la preuve suivante : c'est un des plugins de la collection contenue dans le dossier UserEventPlugins qui suscite l'emballage du service > vraisemblablement en relation avec un appareillage que tu as ajouté au Mac > puisque mettre en quarantaine le dossier complet fait cesser l'emballage.
Mais tu admettras sans mal que verrouiller le dossier complet n'est pas une solution "chirugicale" mais au contraire massive et non satisfaisante. Il conviendra donc de conduire de petites expérimentations sur les plugins de ce dossier > jusqu'à déceler lequel emballe le processus du service. En connaissant son nom > on pourra deviner sa fonction > et par là remonter la piste jusqu'à l'appareil géré.
Comme je ne suis pas du soir > je te propose de remettre cette tâche à demain.
Bonjour Macomaniac et Sebouuuh.
J'ai suivi votre discussion et il se trouve que j'ai le même problème que Sebouuuh. Le processus UserEventAgent s'emballe jusqu'à faire redémarrer l'ordinateur, c'est arrivé hier pour la première fois. (Mon ordi est un Imac de 2010 sous high sierra). La différence avec Sebouuuh c'est que je n'ai installer aucun nouveau matériel sur l'ordinateur mise à part une nouvelle clé Usb.
J'ai donc fait la manip pour mettre en quarantaine le processus comme vu plus haut. Sauf que de puis plus aucun moyen de se connecter à internet que ce soit en wifi ou par cable.
Comment puis je annuler la manip afin de vérifier si cela est lié ?
Merci d'avance
J'ai suivi votre discussion et il se trouve que j'ai le même problème que Sebouuuh. Le processus UserEventAgent s'emballe jusqu'à faire redémarrer l'ordinateur, c'est arrivé hier pour la première fois. (Mon ordi est un Imac de 2010 sous high sierra). La différence avec Sebouuuh c'est que je n'ai installer aucun nouveau matériel sur l'ordinateur mise à part une nouvelle clé Usb.
J'ai donc fait la manip pour mettre en quarantaine le processus comme vu plus haut. Sauf que de puis plus aucun moyen de se connecter à internet que ce soit en wifi ou par cable.
Comment puis je annuler la manip afin de vérifier si cela est lié ?
Merci d'avance
M
Membre supprimé 1060554
Invité
Salut drn.mrn
Le cas du service UserEventAgent qui s'emballe en dévorant de la RAM et en suscitant du swap est un sujet qui n'a pas encore eu d'élucidation.
La commande que j'avais passée à sebouuuh :
Évidemment > c'est une ségrégation "massive" et ça ne m'étonne pas que tu attestes ici d'un effet de blocage collatéral (plus de connexion à internet). Il faut bien que cette collection de plugins serve à quelque chose !
La commande inverse pour redonner au dossier UserEventPlugins_orig renommé son intitulé originel UserEventPlugins est -->
----------
Le dossier UserEventPlugins contient 49 plugins. Ce qu'il s'agit d'expérimenter à présent > c'est non plus une mise en quarantaine du dossier complet > mais d'une sous-partie de la collection des plugins > en les déplaçant dans un dossier externe créé pour l'occasion.
J'ai compté qu'il y a 31 plugins Apple dont l'intitulé commence par : com.apple --> il me sera facile de donner une commande trouvant ces 31 plugins dans le dossier UserEventPlugins et les déplaçant dans le dossier de quarantaine. Après re-démarrage du Mac --> de deux choses l'une : soit le processus UserEventAgent continue de s'emballer > et on saura alors que c'est un des 18 plugins restants qui est responsable ; soit le processus UserEventAgent ne s'emballe plus > et on saura alors que le coupable fait partie du lot des 31 plugins dont le nom commence par com.apple.
Je pense que je vais attendre (à tout seigneur tout honneur !) que le créateur de ce fil sebouuuh y fasse de nouveau acte de présence > pour proposer les commandes effectuant cette petite expérimentation.
----------
J'ai noté par ailleurs qu'il existe dans le bibliothèque personnelle de compte de l'utilisateur > un fichier de préférences relatif au processus UserEventPlugins = UserEventAgent.plist (+ des fichiers annexes). Cette bibliothèque de l'utilisateur est masquée d'affichage par le Finder par défaut > mais la commande :
efface le flag (marqueur) "hidden" qui la soustrayait à l'affichage > et elle se trouve désormais graphiquement bien visible dans l'espace du dossier de compte de l'utilisateur.
Je me demande si la mise en quarantaine de ce fichier hors de la bibliothèque de l'utilisateur (ce qui va susciter la régénération d'un fichier plist neuf) --> pourrait avoir un effet. Parce que, dans une capture du «Moniteur d'activité» donnée précédemment par sebouuuh, le processus UserEventAgent est mentionné comme exécuté non en mode root > mais avec l'identité de l'utilisateur. Ce qui laisse penser que l'emballement est peut-être une affaire d'utilisateur et non celle du Système.
Pour creuser cette piste je vous propose à tous les deux d'aller à : Menu > Préférences Système > Utilisateurs et groupes > de déverrouiller le cadenas d'administration > de presser le bouton + pour créer un nouvel utilisateur et de choisir : statut "Administrateur" > noms (complet & de compte) = toto > mot-de-passe = toto. Cela fait > déloggez-vous de votre session > loggez-vous dans la session toto (avec peut-être un re-démarrage intercalaire) --> y a-t-il toujours emballement du processus UserEventAgent dans cette session neuve ?
Le cas du service UserEventAgent qui s'emballe en dévorant de la RAM et en suscitant du swap est un sujet qui n'a pas encore eu d'élucidation.
La commande que j'avais passée à sebouuuh :
Bloc de code:
sudo mv /System/Library/UserEventPlugins /System/Library/UserEventPlugins_orig- utilise l'exécutable mv (move : changer soit l'intitulé d'un objet > soit son emplacement) pour modifier le nom du dossier de la Bibliothèque du Système : UserEventPlugins à --> UserEventPlugins_orig. Ce changement d'intitulé a pour effet que le processus UserEventAgent ne peut plus accéder aux plugins contenus > à cause du renommage du dossier qui équivaut à une mise-en-quarantaine.
Évidemment > c'est une ségrégation "massive" et ça ne m'étonne pas que tu attestes ici d'un effet de blocage collatéral (plus de connexion à internet). Il faut bien que cette collection de plugins serve à quelque chose !
La commande inverse pour redonner au dossier UserEventPlugins_orig renommé son intitulé originel UserEventPlugins est -->
Bloc de code:
sudo mv /System/Library/UserEventPlugins_orig /System/Library/UserEventPlugins----------
Le dossier UserEventPlugins contient 49 plugins. Ce qu'il s'agit d'expérimenter à présent > c'est non plus une mise en quarantaine du dossier complet > mais d'une sous-partie de la collection des plugins > en les déplaçant dans un dossier externe créé pour l'occasion.
J'ai compté qu'il y a 31 plugins Apple dont l'intitulé commence par : com.apple --> il me sera facile de donner une commande trouvant ces 31 plugins dans le dossier UserEventPlugins et les déplaçant dans le dossier de quarantaine. Après re-démarrage du Mac --> de deux choses l'une : soit le processus UserEventAgent continue de s'emballer > et on saura alors que c'est un des 18 plugins restants qui est responsable ; soit le processus UserEventAgent ne s'emballe plus > et on saura alors que le coupable fait partie du lot des 31 plugins dont le nom commence par com.apple.
Je pense que je vais attendre (à tout seigneur tout honneur !) que le créateur de ce fil sebouuuh y fasse de nouveau acte de présence > pour proposer les commandes effectuant cette petite expérimentation.
----------
J'ai noté par ailleurs qu'il existe dans le bibliothèque personnelle de compte de l'utilisateur > un fichier de préférences relatif au processus UserEventPlugins = UserEventAgent.plist (+ des fichiers annexes). Cette bibliothèque de l'utilisateur est masquée d'affichage par le Finder par défaut > mais la commande :
Bloc de code:
chflags nohidden LibraryJe me demande si la mise en quarantaine de ce fichier hors de la bibliothèque de l'utilisateur (ce qui va susciter la régénération d'un fichier plist neuf) --> pourrait avoir un effet. Parce que, dans une capture du «Moniteur d'activité» donnée précédemment par sebouuuh, le processus UserEventAgent est mentionné comme exécuté non en mode root > mais avec l'identité de l'utilisateur. Ce qui laisse penser que l'emballement est peut-être une affaire d'utilisateur et non celle du Système.
Pour creuser cette piste je vous propose à tous les deux d'aller à : Menu > Préférences Système > Utilisateurs et groupes > de déverrouiller le cadenas d'administration > de presser le bouton + pour créer un nouvel utilisateur et de choisir : statut "Administrateur" > noms (complet & de compte) = toto > mot-de-passe = toto. Cela fait > déloggez-vous de votre session > loggez-vous dans la session toto (avec peut-être un re-démarrage intercalaire) --> y a-t-il toujours emballement du processus UserEventAgent dans cette session neuve ?
Bonjour Macomaniac,
Merci pour ces explications.
J'ai donc créer la session toto et effectivement aucune trace du processus UserEventAgent dans le moniteur d'activité. Même le processus Kernel Task est absent alors que d'habitude il me pompe 400mo en moyenne.
Merci pour ces explications.
J'ai donc créer la session toto et effectivement aucune trace du processus UserEventAgent dans le moniteur d'activité. Même le processus Kernel Task est absent alors que d'habitude il me pompe 400mo en moyenne.
Ça, c'est une illusion d'optique : ce processus est toujours là car, pour faire simple, c'est le coeur du système.
Dans ta session toto, tu n'affiches sans doute que les processus liés au compte de la session, donc tu ne vois pas kernel_task car il est associé au super-utilisateur du système (root).
M
Membre supprimé 1060554
Invité
Salut drn.mrn
Je te propose un petit test en 2 commandes (à passer en copier-coller direct dans le Terminal) -->
=> cette action opérée > re-démarre une fois > et > ta session ré-ouverte > vérifie si le processus UserEventAgent dévore toujours de la RAM.
Je te propose un petit test en 2 commandes (à passer en copier-coller direct dans le Terminal) -->
- 1° par la commande :
tu crées sur ton Bureau de session un dossier d'accueil vide intitulé UEA (acronyme de UserEventAgent)Bloc de code:
mkdir ~/Desktop/UEA
- 2° par la commande :
tu déplaces tous les fichiers dont le nom commence par UserEventAgent > du dossier des Préférences de ta blbliothèque personnelle de compte --> dans le dossier d'accueil UEA du BureauBloc de code:
find ~/Library/Preferences -name 'UserEventAgent*' -exec mv {} ~/Desktop/UEA \;
=> cette action opérée > re-démarre une fois > et > ta session ré-ouverte > vérifie si le processus UserEventAgent dévore toujours de la RAM.
Bonjour Macomaniac,
je sais pas si c'était une bonne idée mais entre temps j'ai effectué la mise à jour 10.13.2
après redémarrage, le processus UserEventAgent n'est plus présent et ne pose plus de plus de problème.
La dernière chose que j'avais fait avant d'avoir le processus UserEventAgent qui s'emballe c'était de brancher une nouvelle clé USB, je ne sais pas si c'était lié mais en tout cas la mise à jour à réglé le problème.
Merci Macomaniac pour ton aide
J'espère que ces échanges pourrons aider d'autres utilisateurs même si c'est dommage qu'au final on ai pas pu trouver l'origine du problème.
je sais pas si c'était une bonne idée mais entre temps j'ai effectué la mise à jour 10.13.2
après redémarrage, le processus UserEventAgent n'est plus présent et ne pose plus de plus de problème.
La dernière chose que j'avais fait avant d'avoir le processus UserEventAgent qui s'emballe c'était de brancher une nouvelle clé USB, je ne sais pas si c'était lié mais en tout cas la mise à jour à réglé le problème.
Merci Macomaniac pour ton aide
J'espère que ces échanges pourrons aider d'autres utilisateurs même si c'est dommage qu'au final on ai pas pu trouver l'origine du problème.
M
Membre supprimé 1060554
Invité
Je suis content que tout soit réglé en ce qui te concerne. Je pense que ça devrait aussi être le cas sebouuuh s'il fait la même mise à jour.
Le "coupable" n'a pas été agrafé mais la partie "traque" dans ce fil a connu des rebondissements divertissants.
Le "coupable" n'a pas été agrafé mais la partie "traque" dans ce fil a connu des rebondissements divertissants.
