Mavericks & IconServicesAgent

SergioSL

Membre enregistré
4 Juillet 2009
8
1
Sur mon MacBook Pro 15" (2008), le "IconServicesAgent" (situé là : /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/XPCServices/com.apple.IconServicesAgent.xpc/Contents/MacOS/com.apple.IconServicesAgent), consomme beaucoup de RAM. Un forum Apple (https://discussions.apple.com/message/23575414#23575414) évoque le problème, mais sans solutions...
Avez-vous rencontré ce problème aussi? Quelqu'un a-t-il une idée de son origine (ce truc m'existait pas avant Mavericks...)?
Merci d'avance.
 
J'ai le même problème, au bout d'un moment le Finder ne répond plus.

La seule "solution" que j'ai trouvé, qui n'en est pas vraiment une, c'est de killer le processus, ce qui remet les choses en place.

J'espère que la mise à jour 10.9.1 règlera ce problème, c'est pénible.
 
C'est ce que je fais aussi via le Moniteur d'activité dont je n'aime guère la nouvelle mouture...
Cela dit, je suis surpris qu'on soit si peu nombreux à signaler ce problème.
 
Dernière édition:
5 utilisateurs touchés, ce n'est pas beaucoup, voire insignifiant.

Encore faudrait-il savoir si vous avec fait une installation par dessus un ancien OS X ou une clean install ?

En ce qui me concerne, clean install depuis le début et aucun problème, mon iMac est allumé toute la journée.
 
Désolé. Je ne voulais embêter personne...
J'ai fait une installation propre ("clean install" en français...).
Dès que j'aurai un moment, j'en tenterai une autre et informerai des résultats.
 
Désolé. Je ne voulais embêter personne...
J'ai fait une installation propre ("clean install" en français...).
Dès que j'aurai un moment, j'en tenterai une autre et informerai des résultats.

Aucun problème, sinon que l'on n'en parle vraiment pas beaucoup. :zen:
 
Merci à tous. Je vais attendre et voir... Mais Mavericks va rester à l'essai sur mon DD externe (à moins que le problème vienne de là?)...
 
Je ne voudrais certes pas troubler la sérénité nirvânique de Locke :coucou: (dont le moins que je puisse dire est qu'il s'avère un maître de l'euphémisme :D en la matière, sans doute parce qu'adepte des installations 'propres', il est exempt du lourd 'karma' de ceux qui procèdent en simple 'mise-à-niveau' d'un OS à l'autre). Mais de mon côté, pratiquant insolemment le procédé 'malpropre' des mises-à-niveau 'depuis la nuit des temps', sans jamais faire de 'Clean Install' (ce qui fait que mon OS actuel «Mavericks 10.9.1» se trimballe encore impudemment des fichiers datant de l'ère pré-industrielle de «Panther 10.3» ☜ :D) - je dois dire que je me suis découvert sous «Mavericks» une 'bête noire' qui, loin d'avoir les proportions entomologiques réglementaires du 'cafard' des cuisines, atteint la cauchemardesque dimension du coléoptère de chambre mutant de la «Métamorphose» de Kafka.

Cet exorde héroïque me conduisant à déclarer qu'en guise probablement de châtiment biblique, je suis affecté du même type de 'plaie égyptienne' que les plaignants de ce fil (Sergio, Sednisil, Christophe et MAKAVELY) : un processus intitulé : 'com.apple.IconService' broute constamment le pré carré de ma RAM dans des proportions qui tendent à augmenter régulièrement, à partir du re-démarrage quotidien de mon Mac, pour atteindre en cours de session une valeur voisine de la consommation en RAM de la 'kernel_task' (soit environ 600 Mo) ; mais, si jamais je lance d'autres sessions sur mon Mac (toutes sous ma houlette : comme une autre session admin et une session root en vue de tests) en activation parallèle (c'est-à-dire en basculant, sans les fermer, d'une identité d'utilisateur à une autre), alors le processus 'com.apple.IconService' dépasse allègrement la valeur de la 'kernel_task' et peut grimper jusqu'au voisinage de 1 Go de RAM immobilisée.

♤

Devant de tels chiffres, il y a de quoi, sinon s'alarmer (un sentiment qui m'est étranger dans le domaine informatique), du moins s'interroger sur la raison_des_effets. Je livre donc ici un aperçu bref de mes élucubrations matutinales sur le sujet.

Comme on sait, le passage de «Mountain Lion 10.8» à «Mavericks 10.9» a été l'occasion pour Apple de changer radicalement les ressources des bibliothèques API supportant l'affichage 'iconographique' de l'OS : alors que, classiquement, il s'agissait des API «QuickTime» ('QuickTime framework' & 'QTKit framework), celles-ci se trouvent 'dépréciées' ('deprecated') sous «Mavericks» qui leur substitue de nouvelles API : 'AVKit framework' reposant sur les protocoles 'AV Foundation'.

Cette abstruse considération théorique me conduit néanmoins à une conséquence 'terre-à-terre' : c'est la fonctionnalité de toile de fond du Finder nommée : «QuickLook» qui a en charge l'affichage 'iconographique' de tout ce qui fait appel à ce type de ressource dans la GUI d'utilisateur : les icônes de fichiers (de toute nature : texte, image, vidéo, musique) ou de dossiers (répertoires aussi bien que bundles d'applications, lesquels ne sont que des espèces spéciales de dossiers recélant un exécutable). Eh bien! le dénommé «QuickLook», depuis qu'il ne va plus chercher du côté des API 'QuickTime' les ressources de sa fonction d'affichage 'iconographique', mais au contraire se réfère à la nouvelle API : 'AVKit framework' conforme au protocole 'AV Foundation', suscite le processus dit : 'com.apple.IconService' comme fil continu de ses opérations.

♧

Ce processus 'com.apple.IconService', qui identifie donc l'opération d'affichage 'iconographique' continu de «QuickLook» sous «Mavericks 10.9», présente 2 effets pervers (qu'on pourrait mettre sur le compte d'une technologie neuve mal rodée) :


  1. une consommation continue de RAM qui n'est pas astreinte à une valeur de seuil 'plafond', et qui donc peut s'envoler pour dépasser la valeur 'critère' dans ce domaine (des activités-système cycliques, de l'ordre de la sous-jacence, et pas des activités quodlibétiques d'utilisateur, comme un encodage vidéo ponctuel) : à savoir celle de la 'kernel_task'. Cette envolée dans la consommation de RAM n'est pas sans pouvoir affecter l'emploi de la CPU - avec tous les 'échauffements' que cela peut impliquer - non plus bien entendu que la marge laissée à l'usage libre de l'utilisateur. Car, si «Mavericks» recourt à la technologie neuve de la 'compressions de mémoire' pour les applications relevant de cet usage libre de la part de l'utilisateur, je ne sache pas que le processus 'com.apple.IconService' soit le moins du monde susceptible de compression. Ce facteur d'immobilisation continue de RAM notable, en cas de taille restreinte de celle-ci, ne peut que susciter le SWAP en débordant la capacité de compression. On serait donc ici dans le cas de figure inverse de l'adage : «Un Bien pour un Mal», à savoir : «Un Mal pour un Bien», le 'bien' de la technique de 'compression mémorielle' se trouvant neutralisé par le 'mal' : 'immobilisation de RAM' de la part du processus 'com.apple.IconService' découlant de la nouvelle API. [Ce qui pourrait apporter de l'eau aux moulins des contempteurs du 'progrès technique', dont les plus modérés défendraient l'idée que, un '-' incalculé compensant toujours à rebours un '+' délibéré, le solde est toujours 'nul' = '0', ce qui fait que le 'Cours_de_l'Histoire' est assujetti à l'inflexible Justice de la stricte égalité en valeur des périodes épochales, c'est-à-dire : la valeur neutre.]


  2. un effet de mise-en-cache des variations diachroniques d'affichage 'iconographique' qui induit une immobilisation grandissante d'espace-disque. En effet, si l'on a la curiosité d'aller à l'adresse : private/var/folders, on s'aperçoit que le susdit répertoire 'folders' recèle des sous-répertoires aux intitulés cryptiques tels que : sg, tf et zz (ce dernier évocateur de mouche tsé-tsé). Lequel zz a la fâcheuse tendance à se remplir indéfiniment de dossiers de type : zyxvpxvq6csfxvn_n0000000000000 [a, b, c, d...n], recelant eux-mêmes des sous-répertoire 'C' et 'T' frappés du sens interdit ; le répertoire sg, quant à lui, recelant un dossier cryptique 'gp09nz8d6kb01vncp7vv9t2r0000gr', lui-même contenant un répertoire 'C' barré du sens interdit ; tandis que le dossier central tf, finalement, contient un dossier au tout aussi cryptique intitulé de type : '0lxn8nrj4nv_yf8qm5bg8f_80000gn' recelant des dossiers 0, C et T dont l'examen dévoile enfin le pot-au-rose ici cliché :


    293144_original.png


    Quelqu'un qui aurait la curiosité maintenant d'aller inspecter le sous-dossier : «Com-apple.IconService» apercevrait ceci :


    293398_original.png


    L'interprétation paraît obvie : le processus 'com.apple.IconService' écrit continûment du cache dans le répertoire 'folders' qui peut être considéré comme 'répertoire_cache' de «QuickLook» notablement, ce non seulement en sous-mode 'itération temporelle' en ce qui conerne les fichiers inclus, mais en outre en mode 'miroir' en ce qui concerne la redondance de dossiers identiques à structure en écho (sans qu'il s'agisse de liens symboliques). Ça peut vite monter en Go ici...

♡

☞ en réaction à cette situation incompressible en mode automatique, personnellement j'use de 2 méthodes de rétorsion connexes dignes de l'arsenal désuet d'un «Exterminateur de cafards» :


  • l'activation régulière du binaire 'purge' (sur lequel un 'SETUID' me permet de me passer des droits 'root' requis pour son activation et de l'activer à l'ancienne avec un banal 'Applescript' enregistré au format 'application'). À défaut de pouvoir purger l'emplacement de la RAM immobilisé par l'effet de cache du processus 'com.apple.IconService', du moins puis-je vaporiser le cache volatile des applications actives et récupérer un équivalent-RAM.

  • la suppression quotidienne a la mano du contenu des dossiers «com.apple.IconService» contenus dans les sous-répertoires 'C' ou 'T' du répertoire global 'folders' de /private/var - quand ce n'est pas, avant re-démarrage ou extinction de mon Mac, la passation d'une commande drastique et totalement dépourvue de scrupules de type : sudo rm sur le contenu du répertoire 'folders' global [Une commande sudo rm dans le «Terminal» ayant potentiellement des pouvoirs dévastateurs entre des mains non avisées, je m'abstiens de la divulagation publique d'icelle dont la syntaxe n'échappera en rien aux experts. Une telle commande radicale, portant effet immédiat de 'tétanisation' de la superbe de «QuickLook» (sans néanmoins blocage d'applications ni du Finder), j'avoue me payer régulièrement le luxe de contempler cette déroute avec un sourire en coin diabolique* <*dit en Anglais : 'evil grin' qu'on peut traduire hardiment par 'sourire vert' si l'on a en vue l'expression Française : 'Diable VauVert' qui prête à Belzébuth, et donc au sourire d'icelui, la couleur 'verte'> avant de relancer mon ordinateur. Icelle relance amenant la reconstruction formelle de l'architecture du répertoire 'folders' que la réactivation du processus 'com.apple.IconService' ne manque pas de venir ré-emplir de contenus aussi itératifs qu'échoatifs (si bompi me passe l'hapax :D).]

&#9826;
 
Dernière édition par un modérateur:
Résumé : Mavericks est codé avec les pieds...
Assez habiles, dans ce cas, les pieds...

[Quand je lis macomaniac me viennent trois références du même champ : Achille Talon, La Rubrique à Brac et Spirou (le célèbre maire de la souriante cité de Champignac, parfois troublée par d'étranges phénomènes) ;) [je ne suis pas sûr d'avoir bien pigé le sens d'échoatif, c'est tout le problème de l'hapax [mot assez rigolo : il vaut mieux faire l'hapax que la guerre ; enterrer l'hapax de guerre et autres calembourgs minables. :rateau: ]]]
 
Dernière édition par un modérateur:
[Quand je lis macomaniac me viennent trois références du même champ : Achille Talon, La Rubrique à Brac et Spirou (le célèbre maire de la souriante cité de Champignac, parfois troublée par d'étranges phénomènes) ;) [je ne suis pas sûr d'avoir bien pigé le sens d'échoatif, c'est tout le problème de l'hapax [mot assez rigolo : il vaut mieux faire l'hapax que la guerre ; enterrer l'hapax de guerre et autres calembourgs minables. :rateau: ]]]

[Sapristi! Percé à jour me suis fait-je dans les ressorts de ma rhétorique amphigourique camouflant sous son imperméable d'imparables méthodes déductives qui furent à l'école du commissaire Bougret... :D. - Quant à l'hapax, Rome en a en la personne papale un qui la dispense uniquement aux hommes de bonne volonté. Pour ne pas parler de couple_hapax, où la volonté de ne faire qu'un se cantonne à l'essai...]
 
Dernière édition par un modérateur:
Créatures et suppôts du Diable, enfants de Satan, moi qui suis le farouche gardien de ces lieux...

Bref, hé les 2 comiques, quand vous aurez fini d'écrire votre thèse philosophique vous nous préviendrez. Allez, soyez sympas, écrivez dans le langage franc-parler d'un Achille Talon.

...sortez donc de ces corps.

Ouais, ouais, ouais, OK, OK...je sors. :D
 
Mon illétrisme dans le domaine des écrits informatiques trouve toujours à exercer sa candeur en suivant les pistes de lecture grâcieusement fournies par François :coucou:.

D'après Google, il y aurait une formule qui exorcise le com.apple.IconServicesAgent :
Bloc de code:
mkdir ${TMPDIR}/com.apple.IconServices
= https://discussions.apple.com/thread/5472367?start=60&tstart=0

&#9828;

J'ai donc lu avec attention le billet du dénommé Kieran Healy, dont le nom de scène 'healy' (que je traduirais par un : 'retourné_à_la_santé_après_accès_maladif') paraît des plus approprié en l'occurrence.

En résumé : ayant constaté sur son Mac des accès temporaires d'enfièvrement de la consommation de CPU, joint à une immobilisation conséquente de RAM, occasionnés par l'Agent : 'IconServices', il s'est demandé pourquoi cela se produisait et comment y pallier.


  1. Pourquoi => son interprétation d'après des messages de la «Console» est que l'Agent en question échouerait à écrire des fichiers temporaires dans un dossier temporaire : «com.apple.IconServices» à l'intérieur du répertoire : /var sous l'effet conjoncturel de tentatives de la part l'utilisateur d'ouvrir tel ou tel dossier personnel recelant des fichiers-images, ce parce que :

    • ledit dossier devant accueillir ces fichiers temporaires n'existe pas à l'adresse attendue de son OS («If you take a look at the named directory in Terminal that the Agent is trying to write to, you&#8217;ll find it isn&#8217;t there») ;

    • ledit Agent n'aurait pas les permissions d'écrire les fichiers temporaires évoqués à l'adresse attendue («the Agent tries to create files in a temporary location in /var/ but is having permission to do this denied»)

  2. Comment => la méthode qu'il préconise est donc de de baliser à l'adresse attendue un 'terrain d'opération' pour que l'Agent puisse effectuer sa tâche sans 'mouliner dans l'échec' :

    • ce, en créant à l'adresse attendue un dossier temporaire : «com.apple.IconServices» avec des permissions : 755 user:staff (soit : drwxr-xr-x) grâce à une commande dans le «Terminal» au chemin abrégé par une variante environnementale = mkdir ${TMPDIR}/com.apple.IconServices.

    • cette création d'un dossier temporaire devrait être ré-itérée pour chaque 'accès d'écriture de fichiers temporaires' de la part de l'Agent, suscitées par les actions d'ouverture de dossiers-images de l'utilisateur, c'est-à-dire à chaque ré-ouverture de la session d'utilisateur («this is necessary at most only once per startup or proper login cycle»)

&#9831;

Je dois dire que, dans mon existence de lecteur exercé aux seules rigueurs de la logique discursive du commissaire Bougret du langage naturel, j'ai rarement eu l'occasion de contempler autant de confusion intellectuelle en si peu de mots.

Parce que, à la racine, le répertoire /var de l'OS n'accueille nullement des 'fichiers temporaires' (réservés au répertoire /tmp), mais des 'fichiers-caches' ; à l'intérieur duquel le sous-répertoire 'folders' n'est aucunement un 'classeur' d'accueil provisoire dédié à une espèce de 'fichiers-temporaires', mais est un sous-répertoire-système, parfaitement structurel, attendu en mode constant, pour l'écriture de 'fichiers-caches' ; à l'intérieur duquel le répertoire au 3è degré : «com.apple.IconServices» n'a rien d'un dossier temporaire servant à accueillir, le temps d'une session, des 'fichiers-temporaires' écrits par un Agent de tâches 'iconographiques' en réponse à des problèmes ponctuels d'ouverture par l'utilisateur d'un dossier d'images personnel, mais est un dossier structurel d'accueil des caches graphiques à l'échelle du Système.

Il ne peut donc pas être question, par une commande du «Terminal» abrégé dans son chemin grâce à une variable environnementale, de créer avec statut de dossier temporaire un répertoire «com.apple.IconServices» requis par le Système comme répertoire-système permanent dédié aux caches graphiques. Si un tel dossier fait défaut dans l'OS du dénommé Healy, c'est tout bonnement que son OS a un problème architectural et devrait être ré-installé.

&#9825;

Cette erreur d'interprétation de la nature du répertoire et des fichiers qu'il doit receler, d'une part s'accompagne d'une incohérence logique chez le susdit, et d'autre part donne lieu à une fuite-en-avant tactique totalement futile :


  • incohérence logique. On ne peut pas simultanément et sous le même rapport supposer qu'un objet n'existe pas (le répertoire «com.apple.IconServices» qui ferait défaut à l'adresse attendue) et que le même objet existe (mais serait doté de permissions insuffisantes à y permettre une tâche d'écriture de fichiers). C'est pourtant ce qu'assume Healy en cherchant contradictoirement à la fois à créer un répertoire temporaire ET à doter de permissions qui lui auraient fait défaut un répertoire temporaire présupposé exister sans elles en tant que raison de l'échec d'écriture de la part de l'Agent. CQFD :D

  • fuite-en-avant tactique. Il est clair que s'assigner la tâche itérative de re-créer à l'ouverture de chaque session un dossier temporaire «com.apple.IconServices» pour accueillir des écritures de fichiers interprétées comme temporaires, alors même que le problème se résume à l'absence d'une répertoire-système attendu dans sa permanence par des écritures cache du Système qui n'ont rien de fichiers temporaires, revient à colmater la fuite d'une durite_vapeur avec une manche de chemise [comme l'improvise brillamment Charlie (aka : Humphrey Bogard) dans «The African Queen» afin de pallier à la pression des urgences politiques de Rosie (aka : Katarina Hepburn].

&#9826;

Car ce n'est pas du tout de cela dont il question dans le sujet abordé :D. Mais simplement que sous «Mavericks» un processus parfaitement structurel et qui n'a rien de temporairement lié à une man&#339;uvre indue d'utilisateur, à savoir le : com.apple.IconServices écrit continûment du cache graphique à un emplacement-système attendu : le dossier «com.apple.IconServices» qui doit donc être présent par défaut dans le répertoire /var/folders. Cette opération d'écriture continue de caches graphiques est indubitablement en relation avec le nouveau dispositif de «Mavericks» consistant dans la lecture directe de caches par le Système, en court-circuitage de celle des fichiers de référence, pour activer les fonctionnalités qui en dépendent : ici, il s'agit de celle de «QuickLook», fonctionnalité d'affichage graphique qui procède par lecture directe des caches graphiques.

Lorsque le dénommé Healy évoque donc un re-création à chaque ouverture de session du dossier d'accueil des caches : «com.apple.IconServices» en tant que dossier temporaire, il pallie manifestement une architecture bancale de son OS par une rustine pathétique conformément à l'adage : mettre un cautère sur une jambe de bois. Et lorsqu'il évoque le fait que ledit dossier temporaire pourra ainsi se remplir tranquillement de la série de fichiers temporaires écrits par l'AgentInside the directory the needed files are now created and IconServicesAgent returns to its normal state of quietude»), il pense être débarrassé du tracas qui le titillait (consommation de la CPU) alors que c'est seulement sur ce point que commence la question que je soulevais : une discutable instruction inhérente à «Mavericks» qui, toutes choses étant dans l'ordre attendu (à savoir un dossier-système «com.apple.IconServices» présent par défaut à l'emplacement attendu), fait écrire une itération indéfinie de fichiers-cache graphiques suite au changement d'API des ressources graphiques (passage des bibliothèques «QuickTime»*à celles de l'«AV Foundation»). Sans parler de la délirante redondance des dossiers «com.apple.IconServices» dans des répertoires parents distribués en une structure en miroir : à savoir le parallélisme des répertoires : 'C'.

-----​

[NB. Il est bien évident que, dans un OS «Mavericks» à l'architecture non bancale, la commande :

Bloc de code:
mkdir ${TMPDIR}/com.apple.IconServices

ne peut qu'échouer dès lors qu'un dossier-système «com.apple.IconServices» est bien déjà présent par défaut à titre permanent sous le même intitulé. Le seul retour de commande possible étant un : file already exists. Par ailleurs, le dossier-système «com.apple.IconServices» ne doit pas être en permissions : 755 user:staff mais en 700 user:staff.]

&#9816;
 
Dernière édition par un modérateur:
Je suis moi aussi perplexe devant cette commande : j'espère que bompi la commentera.

C'est la seule recette qui ait semblé fonctionner pour plusieurs intervenants.
Après, d'autres ont parlé de Boinc, VLC, etc.

Mon impression générale est celle d'un bug inhérent à Mavericks : si c'est bien le cas, Apple pourrait le corriger dans une prochaine mise à jour.