J'ai un daemon qui appelle un bash qui est lancé au démarrage (rc5.d en
S99mondaemon) et qui bouffe toute la cpu.
Ce bash contient un "sleep 0,1" si je le passe à "sleep 1" je n'ai plus
le pb.
Si je restart le daemon tout rentre dans l'ordre.
J'ai essayé de supprimer le lancement automatique du daemon et de le
remplacer par un start dans bootmisc.sh ou rmnologin mais c'est toujours
la même chose.
Quand je dis bouffe la cpu en fait le bash prend que 10% de cpu mais
j'ai 51% de cpu user et 48% de cpu system qui sont consommé et que je ne
retrouve pas sur les process lancés.
J'ai essayé de remplacer le sleep par usleep mais c'est le même pb.
Je ne vois plus trop ou chercher la cause de ce pb.
Je suis en debian 3.0r2 noyau 2.4.18 sur un celeron 2Go avec 512 Mo de
RAM.
éffectivement avec un export de LC_NUMERIC=POSIX et "sleep 0.1" dans le bash je n'ai plus de pb.
Merci à tous pour votre aide
Patrick
Le jeudi 12 mai 2005 à 13:32 +0200, François TOURDE a écrit :
Le 12915ième jour après Epoch, Patrick Noël écrivait:
> oui mais comment expliquer que juste en faisant un restart du daemon je > n'ai plus le pb, la conso cpu redevient normale.
Ben juste parce que les locales ne sont pas les mêmes... Entre le . et la , sleep va réagir de façon différente, générer une erreur (invisible pour toi car tu fais 2>/dev/null), et du coup plus de sleep et conso à fond.
> d'autre part avec un ps -aux je ne vois pas les process qui consomment > la cpu !
C'est 'ls' qui consomme tout, mais tu ne le vois pas car ce n'est jamais le même. Regarde le 'forkrate' et tu vas être surpris ;)
> > Patrick > > Le jeudi 12 mai 2005 à 11:13 +0200, François TOURDE a écrit : >> Le 12915ième jour après Epoch, >> Patrick Noël écrivait: >> >> > le sleep 0.1 me donne "sleep: invalid time interval '0.1'" >> > >> > avec un "sleep 1" cela fonctionne sans problème >> > >> > le daemon lancé est un bash qui surveille la présence de fichiers dans >> > des dossiers pour les envoyer vers d'autres serveurs. Il contient une >> > boucle avec une tempo faite par un "sleep 0,1" >> >> Je m'en doutais ;) >> >> Extrait: >> >> > while [ 1 ] >> > do >> [...] >> > sleep $tempo_util >> > >> > dir=`ls -rt --ignore=tmp.* 2> /dev/null | head -n 1` >> > if [ "$dir" != "" ] >> > then >> [...] >> > fi >> > >> > done >> >> Dans un répertoire initial vide, ton prog boucle indéfiniement et à >> toute vitesse. Selon ta machine, et éventuellement un souci sur la >> commande sleep, tu vas consommer toute la CPU. Tu précises qu'avec un >> sleep 1 ça marche, alors pourquoi ne pas faire ça? >> >> D'autre part, un petit prog avec l'utilisation de select(2) devrait >> pouvoir améliorer l'attente. >>
-- Pensez
éffectivement avec un export de LC_NUMERIC=POSIX et "sleep 0.1" dans le
bash je n'ai plus de pb.
Merci à tous pour votre aide
Patrick
Le jeudi 12 mai 2005 à 13:32 +0200, François TOURDE a écrit :
Le 12915ième jour après Epoch,
Patrick Noël écrivait:
> oui mais comment expliquer que juste en faisant un restart du daemon je
> n'ai plus le pb, la conso cpu redevient normale.
Ben juste parce que les locales ne sont pas les mêmes... Entre le . et
la , sleep va réagir de façon différente, générer une erreur
(invisible pour toi car tu fais 2>/dev/null), et du coup plus de sleep
et conso à fond.
> d'autre part avec un ps -aux je ne vois pas les process qui consomment
> la cpu !
C'est 'ls' qui consomme tout, mais tu ne le vois pas car ce n'est
jamais le même. Regarde le 'forkrate' et tu vas être surpris ;)
>
> Patrick
>
> Le jeudi 12 mai 2005 à 11:13 +0200, François TOURDE a écrit :
>> Le 12915ième jour après Epoch,
>> Patrick Noël écrivait:
>>
>> > le sleep 0.1 me donne "sleep: invalid time interval '0.1'"
>> >
>> > avec un "sleep 1" cela fonctionne sans problème
>> >
>> > le daemon lancé est un bash qui surveille la présence de fichiers dans
>> > des dossiers pour les envoyer vers d'autres serveurs. Il contient une
>> > boucle avec une tempo faite par un "sleep 0,1"
>>
>> Je m'en doutais ;)
>>
>> Extrait:
>>
>> > while [ 1 ]
>> > do
>> [...]
>> > sleep $tempo_util
>> >
>> > dir=`ls -rt --ignore=tmp.* 2> /dev/null | head -n 1`
>> > if [ "$dir" != "" ]
>> > then
>> [...]
>> > fi
>> >
>> > done
>>
>> Dans un répertoire initial vide, ton prog boucle indéfiniement et à
>> toute vitesse. Selon ta machine, et éventuellement un souci sur la
>> commande sleep, tu vas consommer toute la CPU. Tu précises qu'avec un
>> sleep 1 ça marche, alors pourquoi ne pas faire ça?
>>
>> D'autre part, un petit prog avec l'utilisation de select(2) devrait
>> pouvoir améliorer l'attente.
>>
éffectivement avec un export de LC_NUMERIC=POSIX et "sleep 0.1" dans le bash je n'ai plus de pb.
Merci à tous pour votre aide
Patrick
Le jeudi 12 mai 2005 à 13:32 +0200, François TOURDE a écrit :
Le 12915ième jour après Epoch, Patrick Noël écrivait:
> oui mais comment expliquer que juste en faisant un restart du daemon je > n'ai plus le pb, la conso cpu redevient normale.
Ben juste parce que les locales ne sont pas les mêmes... Entre le . et la , sleep va réagir de façon différente, générer une erreur (invisible pour toi car tu fais 2>/dev/null), et du coup plus de sleep et conso à fond.
> d'autre part avec un ps -aux je ne vois pas les process qui consomment > la cpu !
C'est 'ls' qui consomme tout, mais tu ne le vois pas car ce n'est jamais le même. Regarde le 'forkrate' et tu vas être surpris ;)
> > Patrick > > Le jeudi 12 mai 2005 à 11:13 +0200, François TOURDE a écrit : >> Le 12915ième jour après Epoch, >> Patrick Noël écrivait: >> >> > le sleep 0.1 me donne "sleep: invalid time interval '0.1'" >> > >> > avec un "sleep 1" cela fonctionne sans problème >> > >> > le daemon lancé est un bash qui surveille la présence de fichiers dans >> > des dossiers pour les envoyer vers d'autres serveurs. Il contient une >> > boucle avec une tempo faite par un "sleep 0,1" >> >> Je m'en doutais ;) >> >> Extrait: >> >> > while [ 1 ] >> > do >> [...] >> > sleep $tempo_util >> > >> > dir=`ls -rt --ignore=tmp.* 2> /dev/null | head -n 1` >> > if [ "$dir" != "" ] >> > then >> [...] >> > fi >> > >> > done >> >> Dans un répertoire initial vide, ton prog boucle indéfiniement et à >> toute vitesse. Selon ta machine, et éventuellement un souci sur la >> commande sleep, tu vas consommer toute la CPU. Tu précises qu'avec un >> sleep 1 ça marche, alors pourquoi ne pas faire ça? >> >> D'autre part, un petit prog avec l'utilisation de select(2) devrait >> pouvoir améliorer l'attente. >>
