IconServicesAgent, le service énervant de Mojave

J’ai installé Mojave dès que j’ai monté mon dernier hackintosh, fin 2018. Assez rapidement, j’ai remarqué qu’un process nommé « IconServicesAgent » prenait régulièrement (et assez longtemps) une portion non-négligeable de la puissance CPU disponible, typiquement un « core » entier à lui tout seul.

Un autre symptôme était aussi la lenteur d’affichage de plus en plus marquée avec les icônes personnalisées dans le Finder, malgré l’utilisation d’un SSD rapide, assez désagréable à l’usage.

Après avoir parcouru de nombreux forums où des gens se plaignent du même phénomène, en général avec Mojave mais parfois avec High Sierra, voici la seule procédure qui ait vraiment fonctionné pour moi :

  1. Check for any QuickLooks related .plist files. In a terminal:
    • mdfind com.apple.quicklook. -name .plist
  2. I only had files at the system level (specifically within /System/Library/LaunchAgents/). If you have others, modify the directions below to take that into account (re-introducing plist files from the system level back up to the user).
  3. Make some temporary directories to store these plist files, just in case:
    • mkdir ~/tmp-quicklook
  4. Kill the IconServicesAgent:
    • sudo killall -KILL iconservicesagent
  5. Move the plist files to temporary directories:
    • sudo mv /System/Library/LaunchAgents/com.apple.quicklook.* ~/tmp-quicklook/
  6. Reset QuickLook generators and disk cache:
    • qlmanage -r && qlmanage -r cache
  7. Reboot
  8. Move plist files back:
    • sudo mv ~/tmp-quicklook/com.apple.quicklook.* /System/Library/LaunchAgents
  9. Reboot

J’ai fait cette manoeuvre il y a 2-3 mois maintenant, et le processus se tient sagement à sa place depuis lors.

A noter qu’une autre solution, plus simple, semble efficace pour certains utilisateurs :

  1. Remove the main store:
    • sudo rm -rfv /Library/Caches/com.apple.iconservices.store
  2. Remove subsidiary data:
    • sudo find /private/var/folders/ ( -name com.apple.dock.iconcache -or -name com.apple.iconservices ) -exec rm -rfv {} \;
  3. Reboot

WSUS Offline Update / Windows 7

Un bien bel outil que WSUS Offline Update, qui permet de préparer des « packs de déploiement de mises à jour » personnalisés pour les environnements Microsoft. J’ai ainsi pu préparer un « service pack » pour Windows 7 afin de palier la fin du support de l’OS par Microsoft.

L’application s’installe facilement, en mode portable. Une fois lancé, j’ai choisi les réglages suivants :

Fenêtre principale de WSUS Offline Update

Le téléchargement commence après que le bouton « Start » est cliqué. Une fois terminé, le résultat est à récupérer dans le dossier « client » (même chemin que l’appli), et l’installation se lance par l’exécutable « UpdateInstaller.exe » qui s’y trouve. À noter que plusieurs redémarrages peuvent être nécessaires pour que tout soit installé (de mémoire, il m’en a fallu 2).

WordPress : structure des liens et permissions

Afin de pouvoir changer la structure des liens permanents, WordPress a besoin d’accéder en écriture au fichier « .htaccess » du sous-dossier contenant le blog, faute de quoi il devenait impossible d’accéder aux articles via leur nouveau format de lien.

Au passage, profitons-ens pour attribuer des permissions « standard » pour les dossiers et fichiers WordPress.

Sur le Syno, il faut passer par un accès SSH et les commande suivante :

cd /volume1/web/emrys/

sudo chown -R http:http ./

sudo chmod -R 775 ./

https://stackoverflow.com/questions/18352682/correct-file-permissions-for-wordpress

Le fichier « .htaccess » peut avoir besoin d’être un peu moins souple en termes de droits :

sudo chmod 644 .htaccess

Le dossier « wp-uploads » peut éventuellement avoir besoin d’autorisations plus larges, pour permettre des envois de fichiers via l’interface WordPress :

sudo chmod 777 /wp-content/wp-uploads

For archive

Ce blog a vocation à rester purement personnel. Son but est de devenir une sorte de base de donnée de découvertes, d’astuces et autres bidouilles que la tech me permet d’apprendre par moi-même ou par d’autres sources.

J’ai créé ce blog en 15 minutes montre en main (sauf la partie personnalisation qui est à peine commencée…), de manière entièrement hostée sur mon Syno 916+. Petit résumé des étapes suivies :

  1. Création d’une redirection OVH pour l’adresse web emrys.celeri.net et l’adresse mail associée emrys@celeri.net
  2. Création d’une base de données « emrys » dans MariaDB, avec le username eponyme pour y accéder
  3. Création d’un sous-dossier « emrys » dans le dossier « web »
  4. Création d’un Virtual Host dans Web Station avec serveur Apache 2.4 et PHP 7.3, le dossier initial étant celui créé juste avant
  5. Décompression de l’archive téléchargée sur le site de WordPress dans ce sous-dossier
  6. Modification du fichier wp_config.php avec les paramètres correspondants
  7. Lancement de WordPress via l’URL https://emrys.celeri.net
  8. Personnalisation du blog via l’interface d’administration

Ayant déjà installé un certificat « wildcard » pour *.celeri.net sur le Syno, pas besoin d’installer de certificat pour ce nouveau serveur !