Catalina 10.15.4. nervt

[Jörn]

AppStore...

Starte doch mal den App-Store, stochere etwas darin herum, und schaue vor allem, ob Du eingeloggt bist. Wenn alles gut aussieht, beende den App-Store wieder.

Vielleicht bleibt er irgendwo hängen, wenn er im Hintergrund z.B. nach Updates o.ä. sucht.

[Se.Her]

Ich habe sogar etwas ziemlich aktuelles in der Suche gefunden: https://discussions.apple.com/thread/251269574
Das das beschriebene Problem mit nicht-geladener App hatte ich bisher nicht.

Bin im Safe-Mode, kernel_task bleibt ruhig, im App-Store bin ich regulär eingeloggt (war ich vorher auch), ALLE Programme meines Accounts erscheinen mit Wolken-Symbol zum herunterladen.

Ich starte als Versuch Microsoft Remote Desktop aus dem Programme-Ordner: läuft. Ich lade das gleiche Programm aus dem AppStore erneut herunter. Es erscheint im AppStore mit "öffnen" ich öffne: läuft. Im Programme-Ordner wurde es nicht doppelt angelegt, sondern nach dem Herunterladen ersetzt.

Okay, ich mache einen regulären Neustart:
Noch ist der kernel_task ruhig, ReportCrash und diagnostics_agent (beide AppleStoreFoundation) sind wieder da. Und dazu passen dann mglw. auch:

accoundsd (AccountsDaemon): "Cannot check access to a private account type: com.apple.account.AppleAccount"

mdworker (CoreFoundation): All kCFPreferencesCurrentUser domains in this process will be volatile, because homeDirPath starts with /var/empty

Der AppStore öffnet sich aber problemlos, bin angemeldet, alle Apps sind regulär da, außer: Microsoft RemoteDesktop, das ich nun wieder herunterladen soll. Nach einem Start aus dem Programme-Ordner, wird es aber auch im AppStore wieder erkannt. So weit, so unproblematisch.

... Jetzt läuft der Rechner schon ein Weilchen, ReportCrash liefert fleißig weiter Fehler, aber kernel_task hält sich noch zurück. Mal sehen, was morgen wird...

[Se.Her]

Erstaunlich, erstaunlich... kernel_task ist noch immer ruhig. Was auch immer sich da jetzt repariert hat, es sorgt nicht mehr für rauschende Lüfter. Prima! Die Fehlermeldungen laufen zwar noch immer, aber ich stelle keine Beeinträchtigung des laufenden Systems mehr fest.

[mighty_Maxwell]

In der kernel_task ist auch das Hitze-Management von OSX untergebracht, zumindest das letzte Werkzeug was das Betriebssystem gegen zu viel Hitze hat.
Wenn es dem Prozessor zu warm wird und er mit den Lüftern keine ausreichende Kühlung erreichen kann, so tanktet er sich mit s.g. NOPs herunter. NOP steht für "No Operation" und dein Prozessor macht in der Zeit einfach nichts. Diese Funktionalität wird jedenfalls vom kernel_task verwaltet und nimmt mitunter fast 100% bzw. 800% bei 8 Kernen ein - bin mir gerade nicht sicher wie OSX Mehrkerner und ihre Auslastung darstellt.

Könnte es ggf. bei dir auch ein Problem mit der Wärme sein?

Ich kann dieses Verhalten bei meinem MBP herbeiführen indem ich es auf eine weiche Unterlage mit wenig bzw. keinen Luftaustausch lege. Das erst mal ist mir das bei YouTube kurz vorm Schlafen aufgefallen. Das MBP stand direkt auf der Matratze, das Video ruckelte stark und irgendwann fing sogar der Mauszeiger an über das Display zu hüpfen.

[Se.Her]

Ja, das mit der Hitze weiß ich, das konnte aber nicht auf die Außentemperatur zutreffen. Zum einen habe ich die Position und die physische Umgebung des Rechners mit der Installation von Catalina nicht verändert, zum anderen steht der Mac mini frei auf vier Holzwürfeln ohne Kontakt zum Unterboden, also mit freiem Luftaustausch in alle Richtungen.

Ansonsten wird Hitze m. E. schon zutreffen, aber nur durch gezielte Belastung von Rechenprozessen. Die volle Auslastung von 100% wurde nur auf einem von 12 Kernen angezeigt. Hier fand also die Belastung statt, vermutlich wegen einer endlosen Kette von einem oder mehreren gescheiterten Prozessen. Darauf könnte zumindest der Dauereinsatz von ReportCrash (AppStore) hinweisen. Die Belastung nur eines Kerns könnte darauf hinweisen, dass es sich um kleine Prozesse, mglw. nur einen Prozess handelt.

ReportCrash meldet sich auch weiterhin dauernd. Nach dem Neustart gestern Nacht haben Konsole, diagnosticd, WindowsServer, kernel_task und ReportCrash die meiste CPU-Zeit. Konsole am meisten, die anderen danach etwa gleich viel. Das Problem scheint mir nicht behoben, aber es beeinträchtigt zunächst nicht so stark das System, dass kernel_task einen Kern lahmlegen muss.