mon serveur domestique (10.5.6) tourne à fond les ballons sans que je
lui demande grand chose, sauf du partage de fichierC (mais personne ne
s'en sert...) et AppleVNC.
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
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
Eric Levenez
Le 11/04/09 15:54, dans <1iy0mu2.34i0y83eyab2N%, « Philippe Manet » a écrit :
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
Regarde /etc/syslog.conf, puis tous les emplacements cibles des logs. Tu as peut-être un programme qui s'amuse à envoyer continuellement des traces de log. Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd, pour voir ce que fait le programme sur disque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/04/09 15:54, dans <1iy0mu2.34i0y83eyab2N%yapu@invivo.edu>, « Philippe
Manet » <yapu@invivo.edu> a écrit :
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
Regarde /etc/syslog.conf, puis tous les emplacements cibles des logs. Tu as
peut-être un programme qui s'amuse à envoyer continuellement des traces de
log. Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd,
pour voir ce que fait le programme sur disque.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/04/09 15:54, dans <1iy0mu2.34i0y83eyab2N%, « Philippe Manet » a écrit :
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
Regarde /etc/syslog.conf, puis tous les emplacements cibles des logs. Tu as peut-être un programme qui s'amuse à envoyer continuellement des traces de log. Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd, pour voir ce que fait le programme sur disque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
yapu
Eric Levenez wrote:
Regarde /etc/syslog.conf,
rien d'anormal : semblable à celui de ma machine
puis tous les emplacements cibles des logs.
ceux que je lis dans ma console ne semblent pas touchés, mais dans le dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient d'etre mis à jour. ça n'existe pas sur ma machine.
l Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd, pour voir ce que fait le programme sur disque.
ceux que je lis dans ma console ne semblent pas touchés, mais dans le
dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient
d'etre mis à jour.
ça n'existe pas sur ma machine.
l Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd,
pour voir ce que fait le programme sur disque.
ceux que je lis dans ma console ne semblent pas touchés, mais dans le dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient d'etre mis à jour. ça n'existe pas sur ma machine.
l Tu peux faire un "sudo fs_usage xxx", où xxx est le pid de syslogd, pour voir ce que fait le programme sur disque.
Le 11/04/09 20:17, dans <1iy0y3u.kyk3gbld7fl7N%, « Philippe Manet » a écrit :
ceux que je lis dans ma console ne semblent pas touchés, mais dans le dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient d'etre mis à jour. ça n'existe pas sur ma machine.
C'est la base de donnée Apple System Log qui devrait remplacer syslogd.
Les "accept" sont des connexions entrantes, cela peut être local ou via Ethernet. Le but d'asl est de mieux structurer les messages syslog en utilisant de nouvelles API.
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se connecte.
et ça défile en continu...
c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/04/09 20:17, dans <1iy0y3u.kyk3gbld7fl7N%yapu@invivo.edu>, « Philippe
Manet » <yapu@invivo.edu> a écrit :
ceux que je lis dans ma console ne semblent pas touchés, mais dans le
dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient
d'etre mis à jour.
ça n'existe pas sur ma machine.
C'est la base de donnée Apple System Log qui devrait remplacer syslogd.
Les "accept" sont des connexions entrantes, cela peut être local ou via
Ethernet. Le but d'asl est de mieux structurer les messages syslog en
utilisant de nouvelles API.
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se
connecte.
et ça défile en continu...
c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/04/09 20:17, dans <1iy0y3u.kyk3gbld7fl7N%, « Philippe Manet » a écrit :
ceux que je lis dans ma console ne semblent pas touchés, mais dans le dossier private/var/log, il y a asl.db qui fait 21 MO et qui vient d'etre mis à jour. ça n'existe pas sur ma machine.
C'est la base de donnée Apple System Log qui devrait remplacer syslogd.
Les "accept" sont des connexions entrantes, cela peut être local ou via Ethernet. Le but d'asl est de mieux structurer les messages syslog en utilisant de nouvelles API.
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se connecte.
et ça défile en continu...
c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pas.de.spam
Eric Levenez wrote:
> > c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
ben si, justement, beaucoup de guerre sont dues à l'incompréhension ... -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Eric Levenez <usenet@levenez.com> wrote:
>
> c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
ben si, justement, beaucoup de guerre sont dues à l'incompréhension ...
--
PO.
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
ben si, justement, beaucoup de guerre sont dues à l'incompréhension ... -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
yapu
Eric Levenez wrote:
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se connecte.
ne donne rien
> c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
en informatique, il est souvent plus efficace de redemarrer ou de reformater que de chercher à comprendre, meme si c'est moins sastisfaisant... et on a moins de souci ethique qu'en médecine !
et là, en pratique, c'est un powerbook sans écran que je pilote à distance. - si je le laisse fonctionner, le ventilo fonctionne en premanence - le faire redemarrer est pénible
donc, s'il est possible de faire un kill sur syslogd sans que ça perturbe SSH, VNC, le serveur de fichier et le partage iTunes...
-- Philippe Manet en fait, c'est manet avant @
Eric Levenez <usenet@levenez.com> wrote:
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se
connecte.
ne donne rien
> c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
en informatique, il est souvent plus efficace de redemarrer ou de
reformater que de chercher à comprendre, meme si c'est moins
sastisfaisant... et on a moins de souci ethique qu'en médecine !
et là, en pratique, c'est un powerbook sans écran que je pilote à
distance.
- si je le laisse fonctionner, le ventilo fonctionne en premanence
- le faire redemarrer est pénible
donc, s'il est possible de faire un kill sur syslogd sans que ça
perturbe SSH, VNC, le serveur de fichier et le partage iTunes...
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se connecte.
ne donne rien
> c'est ennuyeux de le tuer ?
On ne tue pas quelqu'un juste pace que l'on ne le comprend pas... :-)
en informatique, il est souvent plus efficace de redemarrer ou de reformater que de chercher à comprendre, meme si c'est moins sastisfaisant... et on a moins de souci ethique qu'en médecine !
et là, en pratique, c'est un powerbook sans écran que je pilote à distance. - si je le laisse fonctionner, le ventilo fonctionne en premanence - le faire redemarrer est pénible
donc, s'il est possible de faire un kill sur syslogd sans que ça perturbe SSH, VNC, le serveur de fichier et le partage iTunes...
-- Philippe Manet en fait, c'est manet avant @
yapu
Eric Levenez wrote:
Tu peux peut-être voir avec "sudo lsof -i | grep syslogd" pour savoir qui se connecte.
finalement, j'ai utilisé le mo,iteur d'activité, qui fait un échantillonage de l'activité de syslogd
****************************************** etc.... et ça finit avec : ******************************************
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5): mach_msg_trap 2210 __semwait_signal 1105 select$DARWIN_EXTSN 396 accept$UNIX2003 219 aslevent_handleevent 199 __floatdidf 158 cerror 90 klog_in_close 8 strerror$UNIX2003 6 __error 5 ******************************************
je ne vois pas bien ce qui est là dessous... -- Philippe Manet en fait, c'est manet avant @
fx [François-Xavier Peretmere]
on the 11/04/09 15:54 Philippe Manet wrote the following:
mon serveur domestique (10.5.6) tourne à fond les ballons sans que je lui demande grand chose, sauf du partage de fichierC (mais personne ne s'en sert...) et AppleVNC.
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
on the 11/04/09 15:54 Philippe Manet wrote the following:
mon serveur domestique (10.5.6) tourne à fond les ballons sans que je
lui demande grand chose, sauf du partage de fichierC (mais personne ne
s'en sert...) et AppleVNC.
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
on the 11/04/09 15:54 Philippe Manet wrote the following:
mon serveur domestique (10.5.6) tourne à fond les ballons sans que je lui demande grand chose, sauf du partage de fichierC (mais personne ne s'en sert...) et AppleVNC.
quand je fais un top, j'ai syslogd qui me prend 87% de mon proc
effectivement, ça pourrait bien correspondre à mon souci : je vois bien dans mon espionnage de syslogd qu'il y a un loup avec mDNS. Mais je n'ai pas l'impression de trouver un remède dans les messages cités !
je vais essayer de modifier les réglages réseau ; j'ai une succession de 2 routeurs sur mon réseau, c'est peut-etre un problème. -- Philippe Manet en fait, c'est manet avant @
effectivement, ça pourrait bien correspondre à mon souci : je vois bien
dans mon espionnage de syslogd qu'il y a un loup avec mDNS.
Mais je n'ai pas l'impression de trouver un remède dans les messages
cités !
je vais essayer de modifier les réglages réseau ; j'ai une succession de
2 routeurs sur mon réseau, c'est peut-etre un problème.
--
Philippe Manet
en fait, c'est manet avant @
effectivement, ça pourrait bien correspondre à mon souci : je vois bien dans mon espionnage de syslogd qu'il y a un loup avec mDNS. Mais je n'ai pas l'impression de trouver un remède dans les messages cités !
je vais essayer de modifier les réglages réseau ; j'ai une succession de 2 routeurs sur mon réseau, c'est peut-etre un problème. -- Philippe Manet en fait, c'est manet avant @
