in letzter Zeit hatte ich immer wieder mal, das Problem das einige Programme total skurrile Fehler werfen und abstürzen.

Heute war es mal wieder soweit, dabei mir fiel in der Konsole das hier auf:
-Es tritt nur nachdem der Rechner einige Zeit lief auf.
-Neustart behebt das Problem immer.

Ich benutz macOs 10.15.7 auf nem 2019 macPro.
Hat irgendjemand n Idee wie herausfinden kann was das Problem verursacht? Ich hab einen älteren Hinweiß gefunden der iTunes dafür verantwortlich macht. Ich benutz natürlich Music, aber das beobachte ich mal.

Was meint Disk Utility zur Gesundheit der Disk?

Irgend eine App öffnet jede Menge Dateien und schließt sie nicht. Was waren die letzten Fehlermeldungen vor "kernel: file: table is full" ? Nutzt Du intensiv JAVA? Kann auch eine Folge der "skurrilen Fehler" sein.

nichts... alles Bestens.

Genau, soweit konnte ich mir das auch schon erklären.

Die letzte Fehlermeldung vor dem table is full weiß ich leider nicht mehr, es steht auch echt viel in der Konsole.
Ich acht mal drauf.

Ich nutz Java quasi nicht, es ist zwar installiert .. aber das einzige Programm das es nutzt ist der UniFi Controller den ich nur gelegentlich starte

Ich nutze GeekTool um mir im Hintergrund die Ausgaben des Logs anzeigen zu lassen. Da habe ich im Firmennetz schon mal einen Angriff aufgedeckt, weil ein Rechner versuchte sich per SMB auf meinem Mac einzuloggen und mir das dort so oft angezeigt wurde, dass es mir auffiel. Es macht manchmal Sinn, sich diese Logs anzusehen.

Normalerweise gibt es zwei Limits: die "maxfiles" des Kernel und "maxfiles" per Prozess.
liefert bei mir: 24576 = 0x6000 (hexadezimal) für kern.maxfilesperproc und 49152 = 0xC000 für kernel.maxfiles
An ersterem kann man mit ulimit die Limits erhöhen oder verringern. Da würde ich also mal nachschauen, was da alles so läuft und dann nach dem Übeltäter, eventuell sind es mehrere, suchen.

Wenn ich
im Terminal ausführe (braucht ein wenig), dann erhalte ich 10845 - also es gibt 10845 geöffnete Dateien auf meinem Rechner. Nun könntest du diesen Wert immer mal wieder abrufen (das kann GeekTool auch ganz gut) und dabei eine Anwendung nach der anderen starten - und dabei beobachten, wann sich dieser Wert massiv verändert. Das ist ein wenig lästig und umständlich - aber so kannst du eventuell die Ursache eingrenzen.
Wenn der Wert sprunghaft ansteigt und sich den Limits nähert, dann rufe im Terminal auf. In dieser Datei kannst du dann mit geeigneten Text-Editoren nach dem Prozess suchen, der die meisten offenen Dateien hat.

mir ist aufgefallen das meine externe Backupfestplatte ne Macke hat. Nicht das es damit zu tun hat.

das kommt bei mir:

das Kernel / alle Apps können nur 10240 files offen halten?

Danke erstmal, ich beobachte das mal.

Möglich, dass TimeMachine damit im Hintergrund Probleme hat - aber eigentlich sollte es da keinen File-Descriptor-Leak geben. Sonst wäre das ein Bug in TimeMachine. Aber stecke sie einfach mal ab und schaue, ob das Problem dann weg ist - eine neue Backupfestplatte ist ohnehin angesagt.

So sieht es aus. Ich habe auf meinem Gerät (MBP 2016, macOS 10.15.7) höhere Werte und auf dem Firmen Mac (MBP Late 2013, macOS 10.14.6) ebenfalls. Vielleicht weil beides Entwicklergeräte sind (Simulator führt im Prinzip ein zweites OS aus).
Manche Werte lassen sich per "sysctl" (mit sudo) auch ändern. In der manpage zu sysctl müsste aufgelistet sein, welche Werte sich nicht ändern lassen.

ich änder das einfach mal - bis auf den vermutlich höheren Ram-Verbrauch gibts keine Nachteile?

hab mal in die sysctl.conf

eingefügt

verstaerker

Wenn Du den Fehler finden willst, mußt Du ihn provozieren. Ich hätte kern.maxfilesperproc verkleinert und kern.maxfiles so gelassen. Die Zahl der filesperproc sollte ohnehin kleiner sein als die Gesamtzahl. Bei der vorgeschlagenen Einstellung sollte das System im Fehlerfalle weiterlaufen, so daß Du forschen kannst.

Ich würde auch mal in die System-Logs schauen, vielleicht findest du da einen Hinweis, ob irgendein Prozess vom Kernel beendet wird, weil er zu viele Dateien öffnet.
Hast du eventuell sehr viele Schriften installiert und aktiviert? Für einige Apps wird jede aktive Schrift als Datei geöffnet. Wenn du da jetzt 1000 Schriftdateien aktiv hättest und 10 Prozesse startest (eine App kann mehrere Prozesse via XPC starten), dann hast du das Limit mit 10.000 Dateien schnell erreicht - selbst wenn diese im RAM oft zwischen den Prozessen geshared werden (also nur einmal im Speicher landen) - trotzdem wird für jede Schrift ein File-Descriptor gebraucht.
Da gibt es noch einige andere Dinge, die da Ursache sein können.
Lege mal einen neuen Benutzer an, den du bezüglich Schriften, Cloud-Diensten, Startobjekten, etc. möglichst weit abspeckst. Wenn damit das Problem nicht auftritt - dann liegt es vermutlich daran, dass einer der genannten Dinge im Hintergrund dieses Ressource-Limit überschreitet.

also mit der Fehlersuche wäre ich dann tagelang beschäftigt. Es dauert ja auch ne Weile bis es auftritt.
Da setz ich lieber das Limit hoch und fertig ist.
Sollte es wieder auftreten , weiß ich wo ich gucken muss.

die Änderung der sysctl.conf funktioniert leider nicht , nach einem restart sind wieder die alten Werte am start...

Weiß jemand Rat?

Das hier hab ich schon versucht, ohne Erfolg.

Der Tipp ist nun schon einige Jahre alt und dürfte jetzt nicht mehr funktionieren.
Wie geschrieben: probiere mal einen neuen User mit möglichst wenigen Startobjekten, Schriften, Erweiterungen und beobachte, ob das Problem damit auch auftritt.
Schaue auch mal nach, ob etrecheck was zu berichten hat.

Es ist wieder soweit.
Kannst du mir erklären wie ich das zu lesen hab?

Das sind ja sehr seltsame Werte. Bei mir würde damit wohl überhaupt gar nichts mehr laufen …

Auf meinem Mac Pro 5,1 (2012, nichts Diesbezügliches speziell konfiguriert) mit Mojave 10.14.6 bekomme ich:

Keine Ahnung, ob das einen Einfluss hat, aber wieviel RAM hast Du denn und wie groß ist Deine Systemdisk? Bei mir 48 GB und 4 TB.
Na, einfach zählen, welches COMMAND wie oft vorkommt. Eine einfache Annäherung dafür ist: Datei in TextEdit öffnen, COMMAND (nur die ersten 6 Zeichen, sonst verschluckt sich TextEdit vielleicht) ins Suchfeld eingeben → dann wird Dir rechts im Suchfeld in Grau die Trefferzahl angezeigt (die aber ggf. auch Fundstellen im Dateinamen enthält, daher Annäherung).

Um einen Eindruck zu bekommen, nach welchen COMMANDs Du suchen solltest, einfach die Datei in TextEdit durchscrollen – was superoft vorkommt, wird Dir sofort ins Auge fallen.

Die „Ressourcenschweine“ bei mir zur Zeit:
com.apple = das gesamte macOS inkl. Caching leuchtet ja ein, aber die zwei Java-Apps, die ich laufen habe, sind natürlich katastrophal, zumal die eine davon intern auch noch Chromium benutzt (Chrom selbst läuft bei mir nicht). Und Affinity Photo und das Dock sind auch bemerkenswert. Der gesamte Rest kommt nicht über 500 offene Dateien pro COMMAND.

pCloudFinder integration ist der Spitzenreiter ... 1800
abgeschlagen von Adobe irgendwas .. 800
Final Cut ist auch nicht so schlecht dabei

interessant das deine Werte maxfiles Werte viel höher sind. Ganz ehrlich 10000 kommt mir auch wenig vor.

Ja eben, das verstehe ich auch nicht. Mein kern.maxfiles ist ja das 14fache von Deinem.

im Internet beziehen sich die Leute oft auf diesen 10240 Wert. Denke das ist ein default... vielleicht hast du's ja vor zig Jahren mal modifiziert und vergessen.

Definitiv nicht. Bei mir existiert die Datei /etc/sysctl.conf nicht einmal.

Was natürlich auch heissen könnte, daß du sie vor zig Jahren mal gelöscht haben könntest. Mal rein logisch argumentiert.

Ich habe diese Datei allerdings auch nicht - und bin ganz sicher, in /etc nie und nimmer etwas geändert zu haben.

Klar, könnte es, aber in jedem Fall bestimmen mögliche Einträge in diese Datei dann hier und heute nicht die von sysctl bei mir angezeigten Werte, und nur darum geht es doch hier.

es könnten theoretisch auch Skripte laufen die das beim Systemstart modifizieren

Könnten. Tun sie aber nicht. Auf alles, was beim Systemstart läuft, habe ich ein strenges Auge.

Die von mir geposteten Werte sind bei mir definitiv die Default-Werte. Hier nochmals zum Vergleich:

Wie es der Zufall will, bin ich gerade dabei, einen weiteren Mac Pro 5,1 aufzusetzen, der von der Hardware her identisch mit ersterem ist. macOS 10.14.6 wurde gerade installiert und ist absolut vanilla. Hier das Ergebnis dieses Mac Pro:
kern.maxfiles und kern.maxfilesperproc sind hier absolut identisch; für Mojave 10.14.6 und den Mac Pro 5,1 in meiner RAM/SSD-Bestückung sind das ohne jeden Zweifel die Defaultwerte. vm.vm_page_filecache_min und kern.num_files scheinen variabel zu sein und u.a. von der bisherigen Nutzung abzuhängen.

Hier noch zum weiteren Vergleich ein Mac mini von 2011 mit 2 GB RAM, 8 TB SSD und mit Sierra und HFS+ statt APFS:
Das kommt Deinen Werten weit näher, aber ein Mac Pro 2019 sollte doch etwas mehr auf dem Kasten haben als ein Mac mini von 2011 – von daher scheint bei Dir tatsächlich ein Problem vorzuliegen.

Ich wiederhole meine Frage: Wieviel RAM hat Dein Mac Pro und wie groß ist die Systemdisk?

Vergleiche:

Verschiedene Systeme werden wohl auch verschiedene Defaultwerte haben.

Warum sollte eine neuere macOS-Version nur 1/15 offene Dateien zulassen?

64 GB Ram und 2 TB Systemdisk

Spaßeshalber, macOS 11.01, MBP 2019, 32GB/1TB:
kern.maxfiles: 98304
kern.maxfilesperproc: 49152
kern.corefile: /cores/core.%P
kern.num_files: 7009

MacPro5,1, 10.14:
kern.maxfiles: 1000000
kern.maxfilesperproc: 65536
kern.corefile: /cores/core.%P
kern.num_files: 4478

auf meinem MBP16 mit macOs 10.15.7
32 GB Ram, i9 8 Core, 4 TB SSD

oh wenn ich den Mac Pro im recovery Mode starte
sind die Werte 200000 u 100000

Es ist durchaus möglich, dass manche Installer (die dann Root-Rechte brauchen) diese Werte ändern. Ich kann mir sehr gut vorstellen, dass zum Beispiel die Installation von Xcode (bzw. den Tools beim ersten Start) das tut.
Wenn man eine App in einer iPhone-Simulator-Instanz laufen lässt, dann wird diese Instanz sämtliche Systemdateien von iOS (als i386-Build, Teil von Xcode) darin öffnen. Dabei kann sich die Zahl der geöffneten Dateien fast verdoppeln.
Zudem nicht vergessen, dass auch Netzwerk-Streams zumindest bei lsof als "Datei" gezählt werden, weil es dem Kernel auf diesem Level egal ist, ob die Resource (die Daten) auf lokalen Datenträgern oder auf entfernten Servern liegen.

Wie bereits erwähnt - neben EtreCheck - würde ich, nachdem der Fehler aufgetreten ist, die Syslogs studieren. Der Kernel sollte da eigentlich im Log einen Eintrag hinterlassen, wenn eine Resource nicht geöffnet werden kann. Dort findet man dann möglicherweise Hinweise. Es kann allerdings sein, dass der Fehler in einem anderen Prozess auftritt und nicht in dem, der ihn verursacht.
Du kannst dir auch mit "ps -ax" mal sämtliche laufenden Prozesse anzeigen lassen - oder in "Aktivitätsanzeige" nachschauen. Zum Vergleiche dann man mit einem neuen Benutzer vergleichen und auch mit einem "sicheren Systemstart". Irgendwas spielt da bei deinem aktuellen User nicht "fair".

bei nem Start von BigSur Beta hatte ich auch um die 200000 (das scheint wohl mein Systemdefault)
Ich hab neulich tatsächlich Xcode installiert... vielleicht ist da irgendwas geändert worden

ich suche mal weiter

im abgesicherten Modus auch 200000 - (und meine sysctl.conf Modifikation funktioniert auch - die hab ich jetzt aber rausgenommen)

ich schau mal welche extension es ist

Die Maximalzahl offener Dateien wird von macOS dynamisch beim Start des Betriebssystems (genauer: beim Start des BSD-UNIX-Subsystems) anhand einer Formel eingestellt.

In diese Formel gehen zwei Werte ein:
- die Größe des physischen RAMs
- die Frage, ob der Systemwert "für Server-Betrieb optimieren" ein- oder ausgeschaltet ist.

Ich hab es gefunden:
in /Library/Launchdaemons
waren zwei plists von anydesk, nehm ich die raus sind die Werte

kern.maxfiles: 196608
kern.maxfilesperproc: 98304

sobald die geladen werden, stehen die auf jeweils 10240

Danke Anydesk!
Ich schreib dem support mal.

Heftig!

Aber gut, dass Du den Fehler gefunden hast.

Vielen Dank an Alle für die fachkundige Hilfe die mich auf die richtige Spur gebracht hat!