Mavericks & IconServicesAgent

La seule chose que j'ai vérifiée est la réalité de cette variable d'environnement (TMPDIR) qui est nouvelle elle aussi (je ne sais pas quand elle est apparue mais c'est après Leopard, en tout cas (le seul Mac auquel je puisse présentement accéder étant sous Leopard...)).

Il paraît en tout cas étrange que créer ce dossier suffise mais un bug est par définition une anomalie donc n'a pas forcément à s'expliquer par un raisonnement cohérent (le raisonnement cohérent sera celui explicitant la correction du bug ; c'est là que la critique de macomaniac contre l'infortuné Healy porte à plein :) ).

Tout ça pour dire que je ne suis pas très avancé : je n'ai pas eu jusqu'aujourd'hui à me plaindre de cette gestion de cache par Mavericks ni n'ai creusé ces nouvelles fonctions du système. D'expérience, je sais que les caches peuvent être sources de nombreux problèmes mais c'est tout.

Vous ne voyez rien dans les journaux du système ?
 
Ça existe déjà sous Lion en tout cas:

Bloc de code:
imac-de-bonin:~ bonin$ echo ${TMPDIR}
/var/folders/vk/40gr7qk15cj_hp2ktcxbq5w80000gn/T/
imac-de-bonin:~ bonin$ cd ${TMPDIR}
imac-de-bonin:T bonin$ pwd
/var/folders/vk/40gr7qk15cj_hp2ktcxbq5w80000gn/T
imac-de-bonin:T bonin$ ls
FlashTmp.5zlZMV    FlashTmp.VTv6tt    TemporaryItems    ics213        icssuis501
FlashTmp.IUeBbb    FlashTmp.z4qR17    iPhoto        ics214
Limpide, non ? :D
 
Limpide, non ? :D

☝︎ Ma como lo fai moi trouver la cosa chiarissima e troppo bella ☜ :D



J'ai eu la curiosité de mettre en regard le contenu du répertoire 'folders' de «Snow Léopard» avec celui de «Mavericks» et je propose les deux clichés suivants qui affichent un tableau des éléments significatifs :

'Folders' sous «Snow Léopard»

294097_original.png



'Folders' sous «Mavericks»

293719_original.png

Et dire que Bonaparte déclarait : «Un petit croquis vaut mieux qu'une longue explication»! J'ai bien l'impression, ici, que ces aperçus graphiques du répertoire 'folders' requièrent des annotations marginales.


  • Une constante d'un OS à l'autre : le répertoire 'folders' est essentiellement dédié à des caches et c'est tout à fait marginalement que s'y trouvent un ou deux classeurs à éléments temporaires (tmp) - vides dans mes 2 OS.

  • La situation paraît beaucoup plus confuse au niveau des sous-répertoires de premier ordre dans «Snow Léopard» que dans «Mavericks». «Mavericks» a conservé le sous-répertoire zz de «Snow Léopard» ; par contre il a supprimé la trinité cryptique : GN, qT, Ws pour la réduire au seul sous-répertoire : tf.

    Le sous-répertoire zz est exclusivement dédié aux caches_système (comme le montrent les informations sur les propriétaires des dossiers inclus : Système, Spotlight etc. ; en regard, le sous-répertoire tf est exclusivement dédié aux caches_utilisateur, comme le montrent les informations sur le propriétaire des dossiers inclus : toujours l'user, avec interdiction d'accès pour toute autre instance.

  • Par contre, la situation me paraît logiquement beaucoup plus fumeuse au niveau des éléments 'enfants' de ces sous-répertoires 'parents' sous «Mavericks» que sous «Snow Léopard».

    En effet, la structuration en dossiers_enfants paraît, sous «Mavericks», affectée par un phénomène de redondance de dossiers (répétition topique ou effet_miroir : combien de dossiers 'C'? Combien de dossiers 'T'? Combien de sous-dossiers 'com.apple.dictionary' par exemple?) ; à quoi s'ajoute un phénomène de réitération de fichiers (répétition temporelle ou effet_diachronique : combien de fichiers_caches successifs constituant des 'scans graphiques' dans le dossier : 'com.apple.IconServices'?).

  • «Mavericks» paraît soumis à la loi suprême du cache, qui est déjà une espèce de redondance par rapport au fichier-système racine. Ce qui évoque une volonté de gain de temps dans le fonctionnement, puisque le cache est une redondance 'raccourcie' du fichier de référence, et donc chargeable plus vite. Mais cette politique du 'tout par le cache' (qui implique aussi le chargement du cache du kernel au démarrage en lieu du kernel) semble donner lieu, dans l'organisation de la 'génération des caches', à une prolifération (par redondance topique et par itération diachronique) qui frise l'absurdité.

    Avec des effets pervers : immobilisation de RAM par les processus d'écriture de cache continue (qui contrarie la compression de mémoire) et invasion d'espace-disque par l'expansion continue des fichiers caches. Lequels n'ont rien de temporaire.

  • Le processus 'IconServices', en tant qu'exemple particulier d'opération d'écriture_cache au dossier 'com.apple.IconServices' du répertoire 'Folders', n'a évidemment rien à voir en essence avec une émission de fichiers temporaires. C'est un processus structurel continu qui aligne les scans graphiques diachroniques comme une espèce de 'TimeMachine' du cache graphique saisi de fièvre alimentant l'affichage «QuickLook». Cela n'affecte pas normalement la CPU de façon notable, mais immobilise, en tant qu'opération-système, une part de RAM autour de la valeur de la kernel_task.

☞ voilà quelques petites annotations marginales à ces clichés improvisées sans grande méthode. Je sors un tantinet rêveur et dubitatif de cet exercice, qui me paraît mettre à jour un manque de sobriété logique dans l'organisation de «Mavericks».

♧
 
Je sors un tantinet rêveur et dubitatif de cet exercice, qui me paraît mettre à jour un manque de sobriété logique dans l'organisation de «Mavericks».
Ouais. :rolleyes:
Je ne sais pas si Mavericks a été programmé avec les pieds, si Apple est allé débaucher quelques programmeurs de Microsoft, mais c'est à se demander si ces gens on la moindre notion d'algorithmique et s'ils ont eu une formation en génie logiciel. :zen:
 
Ce qui m'amuse à voir ça, c'est que, de son côté, mon MacBook Pro, avec Mavericks, a enfin un comportement décent. Pas de swap (et consommation de la RAM assez correcte pour la première fois depuis que Mac OS X existe, trouvé-je) pas de ralentissements etc. Et le tout sans bidouiller.

Par ailleurs, je regarde sans doute un peu vite les images ci-dessus mais je ne vois rien de bien choquant [avoir une séparation nette (au moins formelle) entre caches systèmes et caches utilisateurs me paraît une bonne avancée].

Il me semble aussi que l'on va vers un abandon du classique /tmp (en réalité /private/tmp sur Mac OS X), ce qui n'est pas forcément idiot : on a déjà une bonne partie des éléments d'applications organisés suivant la césure système/utilisateurs puis entre utilisateurs, je ne vois pas pourquoi on ne poursuivrait pas cette logique avec les fichiers temporaires.

Ce qui n'explique toujours pas bien ce qui affole IconServices, de fait.
 
Oulala! Quelle discussion!
Merci macomaniac. J'ai bien ri, quand j'ai compris… Car, pour l'essentiel informatique, c'est largement au-dessus de mes compétences.
Je vais donc attendre prudemment un correctif d'Appel. On peut toujours rêver...
 
  • J’aime
Réactions: boninmi
Je me permets de remonter ce post.

La commande suivante permettait d'afficher les programmes qui utilisent com.apple.IconServicesAgent

Bloc de code:
sudo fs_usage -f pathname -w com.apple.IconServicesAgent |grep open

Identifier les programmes qui apparaissent et réinstaller les, cela semble corriger problème.

Topic anglais : https://discussions.apple.com/thread/5472367
 
Salut free00.

Ayant contribué naguère (assez facétieusement) au fil que tu remontes, j'ai été 'alerté' par ton message et j'ai survolé le lien que tu donnes à un fil de 'discussion_Apple' à rallonges.


  • J'en ai tiré l'impression que les intervenants se plaignaient essentiellement du fait que le processus 'com.apple.IconService' enfiévrait le processeur de leur Mac en consommant une proportion phénoménale de CPU. Ce, pour la raison qu'aucun répertoire d'accueil 'com.apple.IconService' n'existait a priori at : private/var/folders/tf notamment, pour accueillir le déluge de fichiers de 'caches_graphiques' : 'xxxx.iscachebmp' générés continûment par ledit processus 'com.apple.IconService'. Le salut serait venu d'un intervenant ayant proposé une commande mkdir dans le «Terminal» permettant de créer le dossier d'accueil lacunaire et ainsi de libérer le processeur de sa tâche de traitement de fichiers caches sans répertoire leur servant de débouché.

  • Mais telle n'était pas la question que j'avais explorée, puisque chez moi le (ou plutôt 'les' - car ils sont légions, distribués dans des sous-arborescences de private/var/folders/) répertoire d'accueil 'com.apple.IconService' existe bel et bien et aucun problème de sur-consommation de CPU n'est à signaler. Non : c'est la consommation de RAM due au processus 'com.apple.IconService' qui m'interpelait, non la consommation de CPU (ce processus parvient à consommer plus de RAM sur mon Mac que la 'kernel_task' elle-même une fois ma session bien lancée, soit > 600 Mo, ce qui n'est pas rien!). Car ce processus génère en continu du fichier_cache graphique de la manière la plus ridicule du monde, et même si le répertoire d'accueil gobal : private/var/folders/ existait déjà dans les OS précédents, jamais par contre je n'avais noté auparavant un processus 'com.apple.IconService' tant soit peu à l'œuvre. Je pense qu'il s'agit d'une innovation de «Mavericks 10.9», contemporaine de l'aggiornamento des bibliothèques de ressources-graphiques (des bibliothèques du QTKIT Code à celles de l'AV-KIT Foundation) --> le processus 'com.apple.IconService' me paraît un processus structurel du Finder sous «Mavericks», par suite je ne vois pas comment il serait possible de suspendre son exercice en identifiant des 'agents_dispensables' qui le susciteraient, car il me semble entièrement solidaire du 'Fonctionnement_Finder' dans 10.9.

    J'ai essayé naguère de court-circuiter complètement ledit processus, et mon Finder a planté instantanément. J'en ai déduit qu'il me fallait faire contre mauvaise fortune bon cœur... [J'ai essayé la commande proposée dans le «Terminal» : 10' après le binaire : fs_usage, en charge de répertorier les 'system_calls', pédalait encore dans la choucroute sans résultat, et j'ai donc coupé court.]
 
Bonjour,

J'ai vu sur le fil de discussion Anglais que les problèmes pouvaient être dû à XCode.

Peux-tu essayer de le désinstaller, vider les /Library/Caches and ~/Library/Caches
et réinstaller Xcode ?
 
Salut à tous,

Juste pour dire à ceux qui chercheraient une solution sur ce forum que le problème(consommation excessive processeur par iconagent) a été résolu chez moi par un rédémarrage en mode safe. Solution repérée en glanant sur plusieurs sites. Cela fait maintenant 3 semaines et plus rien (à part une consommation de ram aux alentours de 120 Mo, mais vu que j'ai 8 go ça passe :) ). J'ai essayé la solution précité

"La commande suivante permettait d'afficher les programmes qui utilisent com.apple.IconServicesAgent
Code:
sudo fs_usage -f pathname -w com.apple.IconServicesAgent |grep open
Identifier les programmes qui apparaissent et réinstaller les, cela semble corriger problème."

Mais chez moi, aucune application tierce ne semblait être engagée dans ce dysfonctionnement.

Bonne continuation à tous, et bonne exploration du monde virtuel ! ( et du réel bien évidemment :) )
 
Salut grantom.

Je vois que tu remontes ce fil où le pisse-copie l'Accro_à_MacGé :D macomaniac avait gribouillé sur le sujet du com.apple.IconServices...

Il me semble que le processus : com.apple.IconServicesAgent soit une innovation de l'OS «Mavericks» - vu que je ne l'avais jamais noté en activité auparavant sous aucun OS antérieur. Pour continuer à filer le brin ténu de mes conjectures : ce processus inédit, donc, me paraît faire corps avec la façon dont «Mavericks» gère l'affichage graphique dans les sessions utilisateurs ouvertes. Si je regarde l'effet produit --> aux adresses contiguës : /private/var/folders/tf/xxxxx/T/com.apple.IconServices & /private/var/folders/tf/xxxxx/C/com.apple.IconServices, se produit une génération continue de fichiers à l'extension : .iscachebmp, qui s'interprètent comme des fichiers caches iconservices au format bitmap. Ce constat (que je n'avais jamais fait sous les OS antérieurs) me laisse penser que, sous «Mavericks», il y a une mise en cache continue d'espèces de 'clichés momentanés' du dispositif graphique global des sessions d'utilisateurs, dépendant soit d'une règle temporelle - toutes les x secondes/minutes - soit d'une règle spatiale - à chaque variation du dispositif graphique.

Ce gonflement du nombre des fichiers_caches .iscachebmp dans les dossiers d'accueil com.apple.IconServices n'est pas indéfini : lesdits dossiers me paraissent subir, notamment, une purge des caches lors de l'extinction-redémarrage du Mac. Mais ça fait quand même une belle collection une fois la session d'utilisateur bien lancée (et encore plus en cas de sessions ouvertes en parallèle) : plusieurs milliers de fichiers allègrement, avec un poids des dossiers se chiffrant par centaines de Mo.

J'avais noté des plaintes sur le net concernant une relation entre ce processus com.apple.IconServicesAgent générateur de caches d'affichage graphique et un enfièvrement de la CPU, mais il me paraît que ce problème était dû à une absence, dans le répertoire : /private/var/folders/tf/xxxxx/T ou C d'un dossier d'accueil : com.apple.IconServices de ces fichiers caches que le processus com.apple.IconServicesAgent avait mission de générer en continu --> en l'absence d'un espace de destination, le processeur devenait 'fou' en quelque sorte. La re-création volontaire de tels dossiers d'accueil com.apple.IconServices aux emplacements attendus 'soulageait' miraculeusement le processeur et les fichiers caches d'affichage graphiques pouvaient s'empiler tranquillement aux emplacements d'accueil requis.

Mes petits bouts de prose humoristique (bien que longuette :D) dans ce fil n'abordaient pas du tout cette question, qui relevait d'une anomalie 'topique', si je puis dire. Non, c'était la pression sur la RAM induite par ce processus inédit : com.apple.IconServicesAgent qui m'avait interpelé, parce que, à mes débuts avec «Mavericks», je constatais régulièrement que ce processus allait jusqu'à prendre autant et plus que la kernel_task, soit plus de 1 Go de RAM une fois la session d'utilisateur bien lancée et spécialement si plusieurs sessions d'utilisateurs étaient ouvertes en parallèle. Il m'avait paru qu'il y avait un lien direct avec la prise en charge en RAM des 2 dossiers de caches d'affichage graphique : com.apple.IconServices en train de gonfler en cours de session.

Le test de purger manuellement ces 2 dossiers de leurs fichiers .iscachebmp (procédé sans effet problématique pour le fonctionnement graphique de la session) et de re-démarrer ramenait immanquablement la pression sur la RAM du processus com.apple.IconServicesAgent à une valeur minimale d'environ 100 Mo - valeur qui, néanmoins, regrimpait inexorablement en cours de session. J'en ai tiré la conclusion qu'il n'y a pas là une anomalie de fonctionnement découlant d'applications de tierce partie, mais une règle de fonctionnement spécifique de «Mavericks» qui est doté d'un processus de mise en cache 'clichant' en continu le dispositif d'affichage graphique dans les sessions d'utilisateurs (c'est secondairement que des applications de tierce partie qui auraient des effets sur cet affichage graphique - un logiciel de 'thèmes' comme «Flavours» peut-être? - seraient susceptibles d'augmenter la charge de cette mise en cache).

Je crois me souvenir m'être amusé naguère, en guise de test, à supprimer manuellement le dossier : folders dans /private/var --> alors là ⛔︎ ! :D --> je ne recommande pas ce type d'expérience si l'on ne possède pas un Système démarrable indépendant, à partir duquel on peut monter les fichiers de l'OS affecté par cette manip afin de rétablir la situation, car le Finder plante instantanément dans sa capacité d'affichage graphique et sauf à recopier un équivalent du dossier en question avec ses multiples composants, c'est fichu...

Ayant il y a quelques mois changé le disque interne de mon MacBook Pro_Early 2011, en remplaçant son HDD par un SSD, j'ai par contre constaté curieusement un effet direct concernant la pression exercée sur la RAM par le processus com.apple.IconServicesAgent : il semble qu'il se stabilise à un maximum d'environ 400 Mo désormais avec le SSD, là où auparavant il grimpait jusqu'à plus de 1 Go avec un HDD, soit moins de la moitié de la kernel_task - ce qui m'a conduit à la mise-en-sommeil de mes interrogations sur le sujet (tant il est vrai que la 'souffrance' est la mère de la connaissance, et l'ignorance la fille de la 'quiétude', d'où l'expression classique d'«imbécile_heureux»... :D).
 
À peu près (ou pas du tout ?) depuis la migration de deux Comptes Snow Leopard sur mon Mac familial Mavericks, je suis victime du pompage de mes 4 Go de RAM par com.apple.IconeServicesAgent.

Et de façon lourde : le Moniteur d'activité me montrait une ligne par session ouverte depuis le précédent redémarrage ! :mad:
Et killer la ligne d'un autre compte (quitté) ne l'empêchait pas de revenir très vite dans le compte ouvert. :eek:
Seule solution simple pour ne plus ramer : redémarrer le Mac, et ne plus changer de compte… :rolleyes:

Le %proc de IconeServicesAgent étant nul dès l'ouverture d'une session après redémarrage, sudo fs_usage n'a rien pu m'apprendre.
Alors, j'ai installé Memory Clean (gratuit sur le MAS), et l'ai paramétré en mode automatique sur chaque session (= sudo purge se déclenche à 25 Mo de mémoire libre) : mon Mavericks a ainsi retrouvé ses 20 ans !


À noter que, outre VLC et XCode, les Apple Communities mentionnent XTra Finder.
 
Dernière édition:
Bon... je me demande si c'est bien raisonnable de déterrer ce sujet : combien de croulants se servent encore de ce vieux fossile qu'est Mavericks ?
Mais comme c'est mon système principal, j'ai bien du trouver une solution ! (j'ai tous les autres mais sur mon iMac 27" 2010 c'est un bon compromis.)

Car régulièrement, j'avais un message "votre disque dur est presque plein" dès que je regardais un peu trop longtemps les centaines de dossiers de photos de ma machine.
Et, bien sûr, comme l'a brillamment expliqué Macomaniac, c'est le cache de iconServiceAgent qui enfle jusqu'à remplir tout le disque !
Plus de 20 Go sur ma machine ce matin.

Alors j'en ai eu marre, et voici ce que j'ai fait :
  • créer une suite de commandes bash avec droits d'administrateur pour vider les deux dossiers de caches d'icones dans /var/folders...
  • l'encapsuler dans un applescript et enregistrer sous forme d'app.
  • enfin, créer un LaunchAgent en .plist dans Library/LaunchAgents, qui lance silencieusement cette app de purge toutes les 5 minutes.

Et le tour est joué : plus de cache d'icônes.
Et le disque système garde imperturbablement sa capacité.
Le pire c'est que ça ne se ressent pas du tout sur l'affichage des icônes : c'est ni plus ni moins rapide (Snow était bien mieux).

Voilà. Ça me troue d'avoir à casser des fonctions de l'OS pour qu'il tourne correctement, mais avec Apple...
 
Bonjour pecos

Bien joué !

- cet IconServicesAgent a été une plaie de l'OS Mavericks. Ce qui fait sourire quand on jette un regard rétrospectif d'un OS actuel sur des OS antérieurs => c'est que les défauts de programmation ou de conception du service d'un OS ne sont jamais corrigés dans les mises à jour de cet OS même, mais dans le remodelage d'un OS suivant. Lequel intègre des défauts de programmation ou de conception neufs (par exemple le défaut de conception de l'espace purgeable dans Sierra 10.12 uniquement corrigé dans High Sierra 10.13. Lequel High Sierra comporte des erreurs de programmation criantes du Service d'Annuaire, jamais corrigées dans cet OS mais dans l'OS Mojave 10.14 consécutif). On ne fait que changer de croix en chemin, tout en se réjouissant de gagner de "nouvelles fonctionnalités"...​
 
Dernière édition par un modérateur:
C'est vrai.
Le pire c'est que ça fait des années que je me sert de Mavericks et je n'avais jamais compris pourquoi la capacité du disque système était aussi... erratique !
Je mettais ça sur le compte du swap file.
Erreur ! c'était le cache des icônes.
Encore merci.