Pourtant en allant à la racine le Finder me trouve moins de 1 To :
Root 0 Go
Utilisateurs 756 Go
Applications 60 Go
Bibliothèque 21 Go
Système 11 Go
opt 3 Go
Developer 0, Mo
Guides de l'utilisateur et informations 60 o
Informations sur l'utilisateur 49 octets
C'est résultats sont cohérents avec les commandes Terminal du.
A propos de ce Mac" me dit qu'il reste 38,62 Go de libre. Mais la barre
de couleur qui détaille les infos est grise sur plus de la moitié, ce
qui est cohérent avec une occupation de moins de 1 To.
Mais la partie grise est indiquée "Système 1,2 To"
Moniteur d'activité me trouve un petit fichier de swap de 663 Mo.
Que passa ?
Est-ce que c'est lié au fait qu'il est en train de crypter le disque de
sauvegarde ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
olivier.marti
Olivier Marti wrote: Une petite session avec le support Apple, en chat puis au téléphone, a permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils ne s'en crée plus, mais je ne sais pas quel appliocation ou processus est le responsable. Bref pour l'instant c'est calme. J'aimerais bien que ça se reproduise pour identifier le responsable. Avec lsof par exemple Olivier
Olivier Marti <olivier.marti@ensta.org> wrote:
Une petite session avec le support Apple, en chat puis au téléphone, a
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas
moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils
ne s'en crée plus, mais je ne sais pas quel appliocation ou processus
est le responsable.
Bref pour l'instant c'est calme. J'aimerais bien que ça se reproduise
pour identifier le responsable. Avec lsof par exemple
Olivier Marti wrote: Une petite session avec le support Apple, en chat puis au téléphone, a permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils ne s'en crée plus, mais je ne sais pas quel appliocation ou processus est le responsable. Bref pour l'instant c'est calme. J'aimerais bien que ça se reproduise pour identifier le responsable. Avec lsof par exemple Olivier
Jean-Pierre Kuypers
In article (Dans l'article) <1nzqpg9.158kk8w1f13djmN%, Olivier Marti wrote (écrivait) :
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ? Parfois cela donne des idées. Le mien par exemple a été modifié le 26 oct 2016. Mais je ne me souviens plus d'un plantage particulier à cette date. Pour info, à toutes fins utiles : <https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores- directory-taking-up-a-lot-of-space> -- Jean-Pierre Kuypers Veuillez découvrir les phrases dans leur con- texte avant de créer sciemment.
In article (Dans l'article)
<1nzqpg9.158kk8w1f13djmN%olivier.marti@ensta.org>, Olivier Marti
<olivier.marti@ensta.org> wrote (écrivait) :
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas
moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ?
Parfois cela donne des idées.
Le mien par exemple a été modifié le 26 oct 2016.
Mais je ne me souviens plus d'un plantage particulier à cette date.
Pour info, à toutes fins utiles :
<https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores-
directory-taking-up-a-lot-of-space>
--
Jean-Pierre Kuypers
Veuillez découvrir les phrases dans leur con-
texte avant de créer sciemment.
In article (Dans l'article) <1nzqpg9.158kk8w1f13djmN%, Olivier Marti wrote (écrivait) :
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ? Parfois cela donne des idées. Le mien par exemple a été modifié le 26 oct 2016. Mais je ne me souviens plus d'un plantage particulier à cette date. Pour info, à toutes fins utiles : <https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores- directory-taking-up-a-lot-of-space> -- Jean-Pierre Kuypers Veuillez découvrir les phrases dans leur con- texte avant de créer sciemment.
Matt
On Jeu 13 décembre 2018 (09:12), Olivier Marti wrote:
Une petite session avec le support Apple, en chat puis au téléphone, a permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils ne s'en crée plus, mais je ne sais pas quel appliocation ou processus est le responsable.
Désactive-les coredumps (cf. man 5 core). On peut également les désactiver en demandant au kernel (cf. man sysctl). Par défaut et malgré ce qu'en dit la page man de core(5) (qui date de 2008), certaines versions de Mac OS X ont la variable « kern.coredump » implicitement activée, activant les coredumps dans /cores hth -- <Yo> Ma mère viens de m'anoncer que mon petit cousin était myopate... <Yo> J'ai pas pu m'enpécher de répondre :" myopate oui mais des banzani"... <Yo> Elle a eu un sourire pis elle ma giflé... * bashfr.org
On Jeu 13 décembre 2018 (09:12),
Olivier Marti <olivier.marti@ensta.org> wrote:
Une petite session avec le support Apple, en chat puis au téléphone, a
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas
moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils
ne s'en crée plus, mais je ne sais pas quel appliocation ou processus
est le responsable.
Désactive-les coredumps (cf. man 5 core).
On peut également les désactiver en demandant au kernel (cf. man
sysctl).
Par défaut et malgré ce qu'en dit la page man de core(5) (qui date de
2008), certaines versions de Mac OS X ont la variable « kern.coredump »
implicitement activée, activant les coredumps dans /cores
hth
--
<Yo> Ma mère viens de m'anoncer que mon petit cousin était myopate...
<Yo> J'ai pas pu m'enpécher de répondre :" myopate oui mais des banzani"...
<Yo> Elle a eu un sourire pis elle ma giflé...
* bashfr.org
On Jeu 13 décembre 2018 (09:12), Olivier Marti wrote:
Une petite session avec le support Apple, en chat puis au téléphone, a permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits, apparemment ils ne s'en crée plus, mais je ne sais pas quel appliocation ou processus est le responsable.
Désactive-les coredumps (cf. man 5 core). On peut également les désactiver en demandant au kernel (cf. man sysctl). Par défaut et malgré ce qu'en dit la page man de core(5) (qui date de 2008), certaines versions de Mac OS X ont la variable « kern.coredump » implicitement activée, activant les coredumps dans /cores hth -- <Yo> Ma mère viens de m'anoncer que mon petit cousin était myopate... <Yo> J'ai pas pu m'enpécher de répondre :" myopate oui mais des banzani"... <Yo> Elle a eu un sourire pis elle ma giflé... * bashfr.org
olivier.marti
Jean-Pierre Kuypers wrote:
In article (Dans l'article) <1nzqpg9.158kk8w1f13djmN%, Olivier Marti wrote (écrivait) :
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ? Parfois cela donne des idées.
C'était des fichiers tous frais du jour, il y en avait quasiment 1 par minute. Mais quand j'ai commencé à investiguer, cette production s'était arrété.
Le mien par exemple a été modifié le 26 oct 2016. Mais je ne me souviens plus d'un plantage particulier à cette date. Pour info, à toutes fins utiles : <https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores- directory-taking-up-a-lot-of-space>
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement. Bizarre ... Je ne vois pas laquelle en fait Mais je vais utiliser la limitation de taille suggérée par cette article. Olivier
In article (Dans l'article)
<1nzqpg9.158kk8w1f13djmN%olivier.marti@ensta.org>, Olivier Marti
<olivier.marti@ensta.org> wrote (écrivait) :
> permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas
> moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ?
Parfois cela donne des idées.
C'était des fichiers tous frais du jour, il y en avait quasiment 1 par
minute. Mais quand j'ai commencé à investiguer, cette production s'était
arrété.
Le mien par exemple a été modifié le 26 oct 2016.
Mais je ne me souviens plus d'un plantage particulier à cette date.
Pour info, à toutes fins utiles :
<https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores-
directory-taking-up-a-lot-of-space>
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Bizarre ... Je ne vois pas laquelle en fait
Mais je vais utiliser la limitation de taille suggérée par cette
article.
In article (Dans l'article) <1nzqpg9.158kk8w1f13djmN%, Olivier Marti wrote (écrivait) :
permis de découvrir 1700 fichiers de environ 800 Mo dans /cores. Pas moyen de savoir qui les a créés. Je l'ai ait détruits
T'as pas noté la date de modification du dossier /cores ? Parfois cela donne des idées.
C'était des fichiers tous frais du jour, il y en avait quasiment 1 par minute. Mais quand j'ai commencé à investiguer, cette production s'était arrété.
Le mien par exemple a été modifié le 26 oct 2016. Mais je ne me souviens plus d'un plantage particulier à cette date. Pour info, à toutes fins utiles : <https://apple.stackexchange.com/questions/215410/os-x-el-capitan-cores- directory-taking-up-a-lot-of-space>
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement. Bizarre ... Je ne vois pas laquelle en fait Mais je vais utiliser la limitation de taille suggérée par cette article. Olivier
Jean-Pierre Kuypers
In article (Dans l'article) <1nzqxml.t4op4wc335s1N%, Olivier Marti wrote (écrivait) :
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump, sans planter. Par ailleurs, en macOS, le fichier reprend le PID ("process identifier") du programme générateur. PID qu'on retrouve aussi dans "Moniteur d'activité", avec le nom de l'application. Mais quand le programme n'est plus actif, c'est trop tard pour aller voir dans "Moniteur d'activité". <https://support.asperasoft.com/hc/en-us/articles/216128238-How-to-gener ate-core-dump-files> -- Jean-Pierre Kuypers Veuillez planter les phrases dans leur con- texte avant de piger sciemment.
In article (Dans l'article)
<1nzqxml.t4op4wc335s1N%olivier.marti@ensta.org>, Olivier Marti
<olivier.marti@ensta.org> wrote (écrivait) :
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump,
sans planter.
Par ailleurs, en macOS, le fichier reprend le PID ("process
identifier") du programme générateur. PID qu'on retrouve aussi dans
"Moniteur d'activité", avec le nom de l'application.
Mais quand le programme n'est plus actif, c'est trop tard pour aller
voir dans "Moniteur d'activité".
In article (Dans l'article) <1nzqxml.t4op4wc335s1N%, Olivier Marti wrote (écrivait) :
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump, sans planter. Par ailleurs, en macOS, le fichier reprend le PID ("process identifier") du programme générateur. PID qu'on retrouve aussi dans "Moniteur d'activité", avec le nom de l'application. Mais quand le programme n'est plus actif, c'est trop tard pour aller voir dans "Moniteur d'activité". <https://support.asperasoft.com/hc/en-us/articles/216128238-How-to-gener ate-core-dump-files> -- Jean-Pierre Kuypers Veuillez planter les phrases dans leur con- texte avant de piger sciemment.
olivier.marti
Jean-Pierre Kuypers wrote:
In article (Dans l'article) <1nzqxml.t4op4wc335s1N%, Olivier Marti wrote (écrivait) :
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump, sans planter. Par ailleurs, en macOS, le fichier reprend le PID ("process identifier") du programme générateur. PID qu'on retrouve aussi dans "Moniteur d'activité", avec le nom de l'application. Mais quand le programme n'est plus actif, c'est trop tard pour aller voir dans "Moniteur d'activité". <https://support.asperasoft.com/hc/en-us/articles/216128238-How-to-gener ate-core-dump-files>
J'ai eu une nouvelle éruption ce matin, mais je l'ai vu trop tard : 135 fichiers pour 105 Go. Ca a commendé au redémarage de la machine après la mise à jour 10.14.2, et a duré 4 heures. J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info utilisable (apparement pas de chaïne de caractère). Je vais envisager de redémarrer et de surveiller ce qui se passe à ce moment la. Le lien entre le nom du core et le numéro de process me sera bien utile en effet. Olivier
In article (Dans l'article)
<1nzqxml.t4op4wc335s1N%olivier.marti@ensta.org>, Olivier Marti
<olivier.marti@ensta.org> wrote (écrivait) :
> Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump,
sans planter.
Par ailleurs, en macOS, le fichier reprend le PID ("process
identifier") du programme générateur. PID qu'on retrouve aussi dans
"Moniteur d'activité", avec le nom de l'application.
Mais quand le programme n'est plus actif, c'est trop tard pour aller
voir dans "Moniteur d'activité".
J'ai eu une nouvelle éruption ce matin, mais je l'ai vu trop tard : 135
fichiers pour 105 Go.
Ca a commendé au redémarage de la machine après la mise à jour 10.14.2,
et a duré 4 heures.
J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info
utilisable (apparement pas de chaïne de caractère).
Je vais envisager de redémarrer et de surveiller ce qui se passe à ce
moment la. Le lien entre le nom du core et le numéro de process me sera
bien utile en effet.
In article (Dans l'article) <1nzqxml.t4op4wc335s1N%, Olivier Marti wrote (écrivait) :
Si je pige bien, il s'agit d'un appli qui se plantait régulèrement.
Les programmes peuvent être capables de (faire) générer un core dump, sans planter. Par ailleurs, en macOS, le fichier reprend le PID ("process identifier") du programme générateur. PID qu'on retrouve aussi dans "Moniteur d'activité", avec le nom de l'application. Mais quand le programme n'est plus actif, c'est trop tard pour aller voir dans "Moniteur d'activité". <https://support.asperasoft.com/hc/en-us/articles/216128238-How-to-gener ate-core-dump-files>
J'ai eu une nouvelle éruption ce matin, mais je l'ai vu trop tard : 135 fichiers pour 105 Go. Ca a commendé au redémarage de la machine après la mise à jour 10.14.2, et a duré 4 heures. J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info utilisable (apparement pas de chaïne de caractère). Je vais envisager de redémarrer et de surveiller ce qui se passe à ce moment la. Le lien entre le nom du core et le numéro de process me sera bien utile en effet. Olivier
Jean-Pierre Kuypers
In article (Dans l'article) <1nztoq1.a92mc6vrrgurN%, Olivier Marti wrote (écrivait) :
J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info utilisable (apparement pas de chaïne de caractère).
J'avais pensé te proposer cela aussi (plutôt od -a, question de goût ou d'habitude), mais de ce que j'ai lu, le nom du programme ne se trouve pas dans le dump. La clé, c'est le PID...
Je vais envisager de redémarrer et de surveiller ce qui se passe à ce moment la. Le lien entre le nom du core et le numéro de process me sera bien utile en effet.
Autres voies peut-être : - Utilitaires -> Console.app - <https://wincent.com/wiki/Debugging_core_dumps_on_OS_X> Bonne chance ! Quand on ne disposait que de 12 Ko de RAM, l'analyse du dump pouvait aider, mais avec les gigas d'aujourd'hui... -- Jean-Pierre Kuypers Veuillez envisager les phrases dans leur con- texte avant de surveiller sciemment.
In article (Dans l'article)
<1nztoq1.a92mc6vrrgurN%olivier.marti@ensta.org>, Olivier Marti
<olivier.marti@ensta.org> wrote (écrivait) :
J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info
utilisable (apparement pas de chaïne de caractère).
J'avais pensé te proposer cela aussi (plutôt od -a, question de goût ou
d'habitude), mais de ce que j'ai lu, le nom du programme ne se trouve
pas dans le dump.
La clé, c'est le PID...
Je vais envisager de redémarrer et de surveiller ce qui se passe à ce
moment la. Le lien entre le nom du core et le numéro de process me sera
bien utile en effet.
In article (Dans l'article) <1nztoq1.a92mc6vrrgurN%, Olivier Marti wrote (écrivait) :
J'ai essayé un octal dump (od -c), mais je n'y vois pas d'info utilisable (apparement pas de chaïne de caractère).
J'avais pensé te proposer cela aussi (plutôt od -a, question de goût ou d'habitude), mais de ce que j'ai lu, le nom du programme ne se trouve pas dans le dump. La clé, c'est le PID...
Je vais envisager de redémarrer et de surveiller ce qui se passe à ce moment la. Le lien entre le nom du core et le numéro de process me sera bien utile en effet.
Autres voies peut-être : - Utilitaires -> Console.app - <https://wincent.com/wiki/Debugging_core_dumps_on_OS_X> Bonne chance ! Quand on ne disposait que de 12 Ko de RAM, l'analyse du dump pouvait aider, mais avec les gigas d'aujourd'hui... -- Jean-Pierre Kuypers Veuillez envisager les phrases dans leur con- texte avant de surveiller sciemment.
