Le MBP de ma femme ventile à fond dès le démarrage. Le 'process viewer'
montre que le proc est à fond tout le temps. Pourtant la liste des
process n'en montre aucun qui consomme beaucoup (bizarre !) ; presque
tous à 0 deux trois à 4-6%. Le petit graph montre surtout du rouge (et
un peu de vert au dessus).
Le MBP de ma femme ventile à fond dès le démarrage. Le 'process viewer' montre que le proc est à fond tout le temps. Pourtant la liste des process n'en montre aucun qui consomme beaucoup (bizarre !) ; presque tous à 0 deux trois à 4-6%. Le petit graph montre surtout du rouge (et un peu de vert au dessus).
Qui a une idée ?
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que les processus de l'utilisateur courant.
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher des processus suivant leur état et leur propriétaire (tout du moins sur Mac OS X 10.6.x).
-- Unfortunate user: Play the Red Hot Chili Peppers Siri: {Displays a list of spicy cooking receipts} (_+_) Siri, part fourteen (_+_)
On Sam 22 juin 2013 (13:46),
Fra <fra@alussinan.org> wrote:
Bonjour
Hello,
Le MBP de ma femme ventile à fond dès le démarrage. Le 'process viewer'
montre que le proc est à fond tout le temps. Pourtant la liste des
process n'en montre aucun qui consomme beaucoup (bizarre !) ; presque
tous à 0 deux trois à 4-6%. Le petit graph montre surtout du rouge (et
un peu de vert au dessus).
Qui a une idée ?
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que
les processus de l'utilisateur courant.
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher
des processus suivant leur état et leur propriétaire (tout du moins sur
Mac OS X 10.6.x).
--
Unfortunate user: Play the Red Hot Chili Peppers
Siri: {Displays a list of spicy cooking receipts}
(_+_) Siri, part fourteen (_+_)
Le MBP de ma femme ventile à fond dès le démarrage. Le 'process viewer' montre que le proc est à fond tout le temps. Pourtant la liste des process n'en montre aucun qui consomme beaucoup (bizarre !) ; presque tous à 0 deux trois à 4-6%. Le petit graph montre surtout du rouge (et un peu de vert au dessus).
Qui a une idée ?
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que les processus de l'utilisateur courant.
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher des processus suivant leur état et leur propriétaire (tout du moins sur Mac OS X 10.6.x).
-- Unfortunate user: Play the Red Hot Chili Peppers Siri: {Displays a list of spicy cooking receipts} (_+_) Siri, part fourteen (_+_)
fra
Matt wrote:
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que les processus de l'utilisateur courant.
En effet ! (Je le découvre.)
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher des processus suivant leur état et leur propriétaire (tout du moins sur Mac OS X 10.6.x).
Bon, le coupable est "syslogd" (120 %). Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et ça a l'air d'aller (quelques pics par 'mds' mais c'est tout). -- Fra
Matt <hfrarg@thelostplatypus.org.invalid> wrote:
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que
les processus de l'utilisateur courant.
En effet ! (Je le découvre.)
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher
des processus suivant leur état et leur propriétaire (tout du moins sur
Mac OS X 10.6.x).
Bon, le coupable est "syslogd" (120 %).
Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et
ça a l'air d'aller (quelques pics par 'mds' mais c'est tout).
--
Fra
Par défaut si ma mémoire est bonne, le moniteur d'activité n'affiche que les processus de l'utilisateur courant.
En effet ! (Je le découvre.)
Dans la barre d'outils, il y a un menu déroulant permettant d'afficher des processus suivant leur état et leur propriétaire (tout du moins sur Mac OS X 10.6.x).
Bon, le coupable est "syslogd" (120 %). Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et ça a l'air d'aller (quelques pics par 'mds' mais c'est tout). -- Fra
fra
Fra wrote:
Bon, le coupable est "syslogd" (120 %). Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et ça a l'air d'aller (quelques pics par 'mds' mais c'est tout).
Redémarage suivant : ventilo à fond ; mais ça s'est calmé le temps que j'ouvre le gestionnaire de taches.
Je viens de lire ça : http://pasizaire.free.fr/Mac/Depannage.html Puis-je vider /private/var/log/ sans conséquences ? Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier asl de 1,5 Go... -- Fra
Fra <fra@alussinan.org> wrote:
Bon, le coupable est "syslogd" (120 %).
Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et
ça a l'air d'aller (quelques pics par 'mds' mais c'est tout).
Redémarage suivant : ventilo à fond ; mais ça s'est calmé le temps que
j'ouvre le gestionnaire de taches.
Je viens de lire ça : http://pasizaire.free.fr/Mac/Depannage.html
Puis-je vider /private/var/log/ sans conséquences ?
Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier
asl de 1,5 Go...
--
Fra
Bon, le coupable est "syslogd" (120 %). Hier soir un redémarage n'y avait rien fait. Là je viens de redémarer et ça a l'air d'aller (quelques pics par 'mds' mais c'est tout).
Redémarage suivant : ventilo à fond ; mais ça s'est calmé le temps que j'ouvre le gestionnaire de taches.
Je viens de lire ça : http://pasizaire.free.fr/Mac/Depannage.html Puis-je vider /private/var/log/ sans conséquences ? Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier asl de 1,5 Go... -- Fra
Matt
On Sam 22 juin 2013 (18:12), Fra wrote:
Redémarage suivant : ventilo à fond ; mais ça s'est calmé le temps que j'ouvre le gestionnaire de taches.
Ce texte n'est pas applicable à Mac OS X <= 10.5.6 (le fichier /var/log/asl.db n'existe plus).
Puis-je vider /private/var/log/ sans conséquences ?
C'est une mauvaise idée car certains de ces historiques sont ouverts par syslogd(8) et aslmanager(8).
Cependant si tu en effaces, pense bien à relancer les daemons cités ci-dessus (incluant newsylog(8)).
Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier asl de 1,5 Go...
/var/log/kernel.log est géré par newsyslog(8). Cette taille me paraît conséquente car newsyslog(8) assure toutes les 30 minutes la maintenance des historiques qui lui sont confiés dans /etc/newsyslog.conf et /etc/newsyslog.d/* Par défaut la taille maximum de /var/log/kernel.log est de 1Mo avant qu'il ne soit archivé par newsyslog(8) et un maximum de 5 achives est gardé dans /var/log (kernel.log.{0..5}.bz2).
/var/log/asl est géré par aslmanager(8). Cette taille me paraît également conséquente car d'après le man d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Garde à l'esprit que la taille de ces historiques dépend des processus qui tournent sur ta machine. Il suffit d'un programme fait avec les pieds pour qu'il remplisse indéfiniment un de ces historiques.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
-- Unfortunate user: On Octobre 29th remind me to call Bob Siri: You're a boob. {repeated 29 times} (_+_) Siri, part eight (_+_)
On Sam 22 juin 2013 (18:12),
Fra <fra@alussinan.org> wrote:
Redémarage suivant : ventilo à fond ; mais ça s'est calmé le temps que
j'ouvre le gestionnaire de taches.
Je viens de lire ça : http://pasizaire.free.fr/Mac/Depannage.html
Ce texte n'est pas applicable à Mac OS X <= 10.5.6 (le fichier
/var/log/asl.db n'existe plus).
Puis-je vider /private/var/log/ sans conséquences ?
C'est une mauvaise idée car certains de ces historiques sont ouverts par
syslogd(8) et aslmanager(8).
Cependant si tu en effaces, pense bien à relancer les daemons cités
ci-dessus (incluant newsylog(8)).
Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier
asl de 1,5 Go...
/var/log/kernel.log est géré par newsyslog(8).
Cette taille me paraît conséquente car newsyslog(8) assure toutes les
30 minutes la maintenance des historiques qui lui sont confiés dans
/etc/newsyslog.conf et /etc/newsyslog.d/*
Par défaut la taille maximum de /var/log/kernel.log est de 1Mo avant
qu'il ne soit archivé par newsyslog(8) et un maximum de 5 achives est
gardé dans /var/log (kernel.log.{0..5}.bz2).
/var/log/asl est géré par aslmanager(8).
Cette taille me paraît également conséquente car d'après le man
d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Garde à l'esprit que la taille de ces historiques dépend des processus
qui tournent sur ta machine. Il suffit d'un programme fait avec les
pieds pour qu'il remplisse indéfiniment un de ces historiques.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas
si c'est toujours le cas avec les versions 10.7 ou 10.8
--
Unfortunate user: On Octobre 29th remind me to call Bob
Siri: You're a boob. {repeated 29 times}
(_+_) Siri, part eight (_+_)
Ce texte n'est pas applicable à Mac OS X <= 10.5.6 (le fichier /var/log/asl.db n'existe plus).
Puis-je vider /private/var/log/ sans conséquences ?
C'est une mauvaise idée car certains de ces historiques sont ouverts par syslogd(8) et aslmanager(8).
Cependant si tu en effaces, pense bien à relancer les daemons cités ci-dessus (incluant newsylog(8)).
Il y a notamment des kernel.log d'1 Go et deux de 500 Mo et un dossier asl de 1,5 Go...
/var/log/kernel.log est géré par newsyslog(8). Cette taille me paraît conséquente car newsyslog(8) assure toutes les 30 minutes la maintenance des historiques qui lui sont confiés dans /etc/newsyslog.conf et /etc/newsyslog.d/* Par défaut la taille maximum de /var/log/kernel.log est de 1Mo avant qu'il ne soit archivé par newsyslog(8) et un maximum de 5 achives est gardé dans /var/log (kernel.log.{0..5}.bz2).
/var/log/asl est géré par aslmanager(8). Cette taille me paraît également conséquente car d'après le man d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Garde à l'esprit que la taille de ces historiques dépend des processus qui tournent sur ta machine. Il suffit d'un programme fait avec les pieds pour qu'il remplisse indéfiniment un de ces historiques.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
-- Unfortunate user: On Octobre 29th remind me to call Bob Siri: You're a boob. {repeated 29 times} (_+_) Siri, part eight (_+_)
mv
Matt wrote:
/var/log/kernel.log est géré par newsyslog(8).
/var/log/asl est géré par aslmanager(8). Cette taille me paraît également conséquente car d'après le man d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log... Par ailleurs, mon dossier asl pèse 2,5 Mo. -- Michel Vauquois Que Dieu vous garde... Moi j'ai pas le temps (RD)
Matt <hfrarg@thelostplatypus.org.invalid> wrote:
/var/log/kernel.log est géré par newsyslog(8).
/var/log/asl est géré par aslmanager(8).
Cette taille me paraît également conséquente car d'après le man
d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas
si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log...
Par ailleurs, mon dossier asl pèse 2,5 Mo.
--
Michel Vauquois
Que Dieu vous garde... Moi j'ai pas le temps (RD)
/var/log/asl est géré par aslmanager(8). Cette taille me paraît également conséquente car d'après le man d'aslmanager(8), la taille de /var/log/asl est par défaut de 150Mo.
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log... Par ailleurs, mon dossier asl pèse 2,5 Mo. -- Michel Vauquois Que Dieu vous garde... Moi j'ai pas le temps (RD)
Matt
On Sam 22 juin 2013 (20:42), MV wrote:
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log...
Relis bien ce que j'ai dis ci-dessus.
Par ailleurs, mon dossier asl pèse 2,5 Mo.
C'est super méga génial. Mais je ne vois pas en quoi cela va aider notre ami Fra, c'te histoire :->
-- Unfortunate user: Play the Red Hot Chili Peppers Siri: {Displays a list of spicy cooking receipts} (_+_) Siri, part fourteen (_+_)
On Sam 22 juin 2013 (20:42),
MV <mv@orage.fr.invalid> wrote:
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas
si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log...
Relis bien ce que j'ai dis ci-dessus.
Par ailleurs, mon dossier asl pèse 2,5 Mo.
C'est super méga génial. Mais je ne vois pas en quoi cela va aider notre
ami Fra, c'te histoire :->
--
Unfortunate user: Play the Red Hot Chili Peppers
Siri: {Displays a list of spicy cooking receipts}
(_+_) Siri, part fourteen (_+_)
Attention : tout ceci est valable pour Mac OS X 10.6.x; je ne sais pas si c'est toujours le cas avec les versions 10.7 ou 10.8
J'ai Mountain Lion et je n'ai pas de kernel.log...
Relis bien ce que j'ai dis ci-dessus.
Par ailleurs, mon dossier asl pèse 2,5 Mo.
C'est super méga génial. Mais je ne vois pas en quoi cela va aider notre ami Fra, c'te histoire :->
-- Unfortunate user: Play the Red Hot Chili Peppers Siri: {Displays a list of spicy cooking receipts} (_+_) Siri, part fourteen (_+_)
fra
Matt wrote:
Garde à l'esprit que la taille de ces historiques dépend des processus qui tournent sur ta machine. Il suffit d'un programme fait avec les pieds pour qu'il remplisse indéfiniment un de ces historiques.
Merci pour ces infos. Ils faut donc que je trouve le process qui (a) rempli ces logs comme un ouf. Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé et le kernel de base a retrouvé une taille normale. Serai t il possible qu'à un moment le fichier de log kernel ai grossit beaucoup et que le fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook) -- Fra
Matt <hfrarg@thelostplatypus.org.invalid> wrote:
Garde à l'esprit que la taille de ces historiques dépend des processus
qui tournent sur ta machine. Il suffit d'un programme fait avec les
pieds pour qu'il remplisse indéfiniment un de ces historiques.
Merci pour ces infos. Ils faut donc que je trouve le process qui (a)
rempli ces logs comme un ouf.
Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé
et le kernel de base a retrouvé une taille normale. Serai t il possible
qu'à un moment le fichier de log kernel ai grossit beaucoup et que le
fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf
puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook)
--
Fra
Garde à l'esprit que la taille de ces historiques dépend des processus qui tournent sur ta machine. Il suffit d'un programme fait avec les pieds pour qu'il remplisse indéfiniment un de ces historiques.
Merci pour ces infos. Ils faut donc que je trouve le process qui (a) rempli ces logs comme un ouf. Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé et le kernel de base a retrouvé une taille normale. Serai t il possible qu'à un moment le fichier de log kernel ai grossit beaucoup et que le fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook) -- Fra
Matt
On Sam 22 juin 2013 (20:59), Fra wrote:
Merci pour ces infos. Ils faut donc que je trouve le process qui (a) rempli ces logs comme un ouf. Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé et le kernel de base a retrouvé une taille normale. Serai t il possible qu'à un moment le fichier de log kernel ai grossit beaucoup et que le fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook)
Oui c'est possible. Pourquoi un processus se priverait par défaut d'utiliser des ressources si celles-ci sont disponibles ? Pour remédier à ça on peut utiliser renice(8) (via sudo(8)) pour baisser la priorité d'un processus en cours (attention les valeurs négatives augmentent la priorité et inversement des valeurs positives diminuent celle-ci. La priorité par défaut est 0; la maximale est -20 et de 20 pour la minimale).
Par contre après le message de Michel, j'ai regardé pourquoi il disait ne pas avoir /var/log/kernel.log
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans /var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log, grossissant inexorablement à des tailles ahurissantes comme tu as pu le constater :)
Pour savoir si c'est le cas, Il faudrait que tu compares entre un <= 10.8.1 et un >= 10.8.2 les fichiers :
-- Unfortunate user: Open Downcasts/tweetbot/Safari/1password/Warcraft/etc Siri: The forecast for today is cloudy. (_+_) Siri, part five (_+_)
On Sam 22 juin 2013 (20:59),
Fra <fra@alussinan.org> wrote:
Merci pour ces infos. Ils faut donc que je trouve le process qui (a)
rempli ces logs comme un ouf.
Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé
et le kernel de base a retrouvé une taille normale. Serai t il possible
qu'à un moment le fichier de log kernel ai grossit beaucoup et que le
fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf
puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook)
Oui c'est possible. Pourquoi un processus se priverait par défaut
d'utiliser des ressources si celles-ci sont disponibles ?
Pour remédier à ça on peut utiliser renice(8) (via sudo(8)) pour baisser
la priorité d'un processus en cours (attention les valeurs négatives
augmentent la priorité et inversement des valeurs positives diminuent
celle-ci. La priorité par défaut est 0; la maximale est -20 et de 20
pour la minimale).
Par contre après le message de Michel, j'ai regardé pourquoi il disait
ne pas avoir /var/log/kernel.log
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans
/var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de
la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de
figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log,
grossissant inexorablement à des tailles ahurissantes comme tu as pu le
constater :)
Pour savoir si c'est le cas, Il faudrait que tu compares entre un
<= 10.8.1 et un >= 10.8.2 les fichiers :
Merci pour ces infos. Ils faut donc que je trouve le process qui (a) rempli ces logs comme un ouf. Depuis bzip2 a saturé le proc et semble avoir créé un kernel log zippé et le kernel de base a retrouvé une taille normale. Serai t il possible qu'à un moment le fichier de log kernel ai grossit beaucoup et que le fait qu'il n'ai jamais le temps de le zipper pour en faire un neuf puisse faire saturer le mac ? (Quand ça rame ma femme ferme le macbook)
Oui c'est possible. Pourquoi un processus se priverait par défaut d'utiliser des ressources si celles-ci sont disponibles ? Pour remédier à ça on peut utiliser renice(8) (via sudo(8)) pour baisser la priorité d'un processus en cours (attention les valeurs négatives augmentent la priorité et inversement des valeurs positives diminuent celle-ci. La priorité par défaut est 0; la maximale est -20 et de 20 pour la minimale).
Par contre après le message de Michel, j'ai regardé pourquoi il disait ne pas avoir /var/log/kernel.log
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans /var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log, grossissant inexorablement à des tailles ahurissantes comme tu as pu le constater :)
Pour savoir si c'est le cas, Il faudrait que tu compares entre un <= 10.8.1 et un >= 10.8.2 les fichiers :
-- Unfortunate user: Open Downcasts/tweetbot/Safari/1password/Warcraft/etc Siri: The forecast for today is cloudy. (_+_) Siri, part five (_+_)
fra
Matt wrote:
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans /var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log, grossissant inexorablement à des tailles ahurissantes comme tu as pu le constater :)
J'ai pas tout compris mais le MBP en question est sous 10.6.8 -- Fra
Matt <hfrarg@thelostplatypus.org.invalid> wrote:
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans
/var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de
la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de
figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log,
grossissant inexorablement à des tailles ahurissantes comme tu as pu le
constater :)
J'ai pas tout compris mais le MBP en question est sous 10.6.8
--
Fra
Apparemment depuis 10.8.2 le canal kern.* est catalogué dans /var/log/system.log et il se peut que newsyslog(8) ne s'occupe plus de la rotation de /var/log/kernel.log
Ceci couplé à une mise à jour qui n'a pas pris en charge ce cas de figure, aurai laissé kern.* se fourrer dans /var/log/kernel.log, grossissant inexorablement à des tailles ahurissantes comme tu as pu le constater :)
J'ai pas tout compris mais le MBP en question est sous 10.6.8 -- Fra
Matt
On Sam 22 juin 2013 (21:32), Fra wrote:
J'ai pas tout compris mais le MBP en question est sous 10.6.8
D'après tes en-têtes j'avais déduis que c'était pour un 10.8
Concernant /var/log/kernel.log, bien que newsyslog(8) est lancé toutes les 30 minutes, tu peux forcer la rotation avec :
$ sudo newsyslog -vF
Concernant /var/log/asl, on peut jouer avec aslmanager(8) et l'option -size en modifiant /System/Library/LaunchDaemons/com.apple.aslmanager.plist, et modifier la taille de chaque fichier dans /var/log/asl en éditant /etc/asl.conf (grâce à « max_file_size ») mais cela ne permet pas de trouver l'origine de ton problème, qui à mon avis reste un processus qui remplit continuellement sans arrêt les historiques.
Poste-nous le résultat de :
$ ls -lht /var/log/asl
-- Unfortunate user: I'm hot. Find doctors in my location. Siri: It's only 8°. I don't find that particularly hot. (_+_) Siri, part sixteen (_+_)
On Sam 22 juin 2013 (21:32),
Fra <fra@alussinan.org> wrote:
J'ai pas tout compris mais le MBP en question est sous 10.6.8
D'après tes en-têtes j'avais déduis que c'était pour un 10.8
Concernant /var/log/kernel.log, bien que newsyslog(8) est lancé toutes
les 30 minutes, tu peux forcer la rotation avec :
$ sudo newsyslog -vF
Concernant /var/log/asl, on peut jouer avec aslmanager(8) et l'option
-size en modifiant /System/Library/LaunchDaemons/com.apple.aslmanager.plist,
et modifier la taille de chaque fichier dans /var/log/asl en éditant
/etc/asl.conf (grâce à « max_file_size ») mais cela ne permet pas de
trouver l'origine de ton problème, qui à mon avis reste un processus qui
remplit continuellement sans arrêt les historiques.
Poste-nous le résultat de :
$ ls -lht /var/log/asl
--
Unfortunate user: I'm hot. Find doctors in my location.
Siri: It's only 8°. I don't find that particularly hot.
(_+_) Siri, part sixteen (_+_)
J'ai pas tout compris mais le MBP en question est sous 10.6.8
D'après tes en-têtes j'avais déduis que c'était pour un 10.8
Concernant /var/log/kernel.log, bien que newsyslog(8) est lancé toutes les 30 minutes, tu peux forcer la rotation avec :
$ sudo newsyslog -vF
Concernant /var/log/asl, on peut jouer avec aslmanager(8) et l'option -size en modifiant /System/Library/LaunchDaemons/com.apple.aslmanager.plist, et modifier la taille de chaque fichier dans /var/log/asl en éditant /etc/asl.conf (grâce à « max_file_size ») mais cela ne permet pas de trouver l'origine de ton problème, qui à mon avis reste un processus qui remplit continuellement sans arrêt les historiques.
Poste-nous le résultat de :
$ ls -lht /var/log/asl
-- Unfortunate user: I'm hot. Find doctors in my location. Siri: It's only 8°. I don't find that particularly hot. (_+_) Siri, part sixteen (_+_)
