Comment puis-je diagnostiquer ou réparer le CalendarAgent occupant un processeur entier sur Mountain Lion?

13

Depuis que je suis passé de Mountain Lion à Lion, je vois que le processus CalendarAgent occupe une grande quantité de 1 CPU sur mon MacBook Pro fin 2008. Pour résoudre ce problème (comme suggéré par un résultat Google), j'ai essayé de supprimer tous les comptes d'agenda en ligne, puis de les ajouter à nouveau. Cela semblait fonctionner pendant un certain temps, mais maintenant le problème est revenu (peut-être à cause de la suppression de certains calendriers iCloud ou de l'ajout d'un délégué de calendrier Google supplémentaire). Je ne veux pas vraiment avoir à supprimer tous mes comptes d'agenda à chaque fois que j'ajoute ou supprime un seul agenda, est-ce que quelqu'un peut m'indiquer la cause première du problème?

Au cas où cela serait utile, le graphe d'appel du processus est collé ici .

MISE À JOUR: J'ai supprimé l'un des délégués de l'un de mes comptes d'agenda Google, et cela a empêché ce problème de se produire. Ce n'est pas vraiment une solution, car je ne peux plus accéder à ce calendrier.

— Nick Hawes
source

Y a-t-il des calendriers Microsoft Exchange auxquels vous avez accès via la messagerie Web Exchange? Si c'est le cas, connectez-vous au compte Exchange et ignorez tous les rappels. Si vous n'avez pas accès aux calendriers Exchange, demandez aux propriétaires de rejeter tout rappel.

— IconDaemon

Vous voudrez peut-être lire cet article pour une autre solution: robert.accettura.com/blog/2012/08/19/…

— IconDaemon

3

Je cherche toujours une réponse solide.

En attendant, j'ai le script suivant exécuté dans AppleScript Editor. Ce script recherche CalendarAgenttoutes les 15 secondes et tue le processus.

Cela rend la synchronisation du calendrier inutilisable, mais au moins je peux réutiliser mon Mac. Je laisserai cela fonctionner jusqu'à ce que je trouve une solution permanente.

Le script est:

repeat
  set app_name to "Finder"
  do shell script "killall -9 CalendarAgent"
  delay 15
end repeat

— JBM
source

Je ne suis jamais vraiment allé au fond des choses, même si c'était une solution aux symptômes, donc d'accepter.

— Nick Hawes

9

Peut avoir à tuer et reconstruire la base de données de calendrier:

Désactivez le service Calendrier de votre compte dans Préférences Système → Comptes Internet
Supprimez les préférences / fichiers de base de données pour le calendrier:
```
rm -r ~/Library/Calendars/ ~/Library/Preferences/com.apple.iCal.plist
```
Réactivez le service.

^{Source: http://robert.accettura.com/blog/2012/08/19/how-to-stop-calendaragent-from-eating-cpu/}

— kappadiva
source

2

Bienvenue sur le site. Nous encourageons les gens à résumer les liens, mais c'est OK de simplement contribuer des liens en sachant qu'ils sont parfois convertis en commentaires ou rejetés alors que nous essayons d'amener les gens à contribuer au corps de connaissances ici sous licence CC.

— bmike

1

A travaillé pour moi. Rappelez-vous: lors de la réactivation, il consomme du CPU pendant un petit moment.

— joost

4

L'utilisation de délégués Google a définitivement causé le problème de CPU élevé avec moi.

La solution simple est de:

Décochez la délégation avec la fenêtre d'informations sur le compte du calendrier (comme indiqué par la MISE À JOUR ci-dessus)
Modifiez le partage de votre calendrier Google en sélectionnant le ou les calendriers souhaités sur la page Paramètres de synchronisation Google: https://www.google.com/calendar/syncselect

Cette modification a éliminé le problème de CPU élevé, sans avoir à recourir à l'approche kill-the-CalendarAgent.

— Dan C
source

Merci pour cela! J'en suis frustré depuis des années. En utilisant le lien syncselect (élément n ° 2) ci-dessus, j'ai désactivé quelques calendriers que je n'ai pas vraiment besoin de synchroniser et je n'ai pas vu le problème de CPU élevé depuis. Bien sûr, cela les supprime de tous les appareils synchronisés (ordinateur de bureau, ordinateur portable et téléphone), mais si cela corrige le processeur élevé que je rencontrais sur le bureau, cela en vaut la peine. Merci encore!

— Steve Lemke