hello

today I found the remote system extremely slow.
I looked up top
and saw this:

pid user pr ni virt res shr s %CPU
%mem TIME+ command

659 root 20 0 20012 10m 476 R 98.2 23.5
201:59:93 updatedb


I killed but it seems strange

thank you

serge_moscou wrote:

> hello
>
> today I found the remote system extremely slow.
> I looked up top
> and saw this:
>
> pid user pr ni virt res shr s %CPU
> %mem TIME+ command
>
> 659 root 20 0 20012 10m 476 R 98.2 23.5
> 201:59:93 updatedb
>
>
> I killed but it seems strange
>
> thank you


You shouldn't be using your computer at 4:40am. Get some sleep. Its a cron
job that's setup by default to update the slocate database. It basically
lets you find files quickly. Try 'slocate xorg.conf' or if you want to find
a fortune, try 'slocate fortune' =)

Look at /var/spool/cron/crontabs if you want to change the time that the
cron.daily runs.

This is the script that was run when you got the "problem":

$cat /etc/cron.daily/slocate
#!/bin/sh
/usr/bin/updatedb -c /etc/updatedb.conf



Enjoy.


--
Posted via a free Usenet account from http://www.teranews.com

well, thank you
but i know this


The problem is that updatedb NEVER STOPS.
I reproduced the event by reruning updatedb
it started 3 hours agos and and still is runing eating up all resources.
It won't stop till I kill it. That is the problem.

I know how updatedb should run normally and what I have must be a sort of a
bug (?)




"Miguel De Anda" <miguel@thedeanda.com> ???????/???????? ? ????????
?????????: news:45fba028$0$20193$88260bb3@free.teranews.com.. .
> serge_moscou wrote:
>
>> hello
>>
>> today I found the remote system extremely slow.
>> I looked up top
>> and saw this:
>>
>> pid user pr ni virt res shr s %CPU
>> %mem TIME+ command
>>
>> 659 root 20 0 20012 10m 476 R 98.2 23.5
>> 201:59:93 updatedb
>>
>>
>> I killed but it seems strange
>>
>> thank you
>
>
> You shouldn't be using your computer at 4:40am. Get some sleep. Its a cron
> job that's setup by default to update the slocate database. It basically
> lets you find files quickly. Try 'slocate xorg.conf' or if you want to
> find
> a fortune, try 'slocate fortune' =)
>
> Look at /var/spool/cron/crontabs if you want to change the time that the
> cron.daily runs.
>
> This is the script that was run when you got the "problem":
>
> $cat /etc/cron.daily/slocate
> #!/bin/sh
> /usr/bin/updatedb -c /etc/updatedb.conf
>
>
>
> Enjoy.
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>

and now to top it
I 'm even unable to kill updatedb process

I do:

# kill 1044 (which updatedb pid)

then

# top or ps

it is still there and running

What's going on?

Thank you

"Miguel De Anda" <miguel@thedeanda.com> ???????/???????? ? ????????
?????????: news:45fba028$0$20193$88260bb3@free.teranews.com.. .
> serge_moscou wrote:
>
>> hello
>>
>> today I found the remote system extremely slow.
>> I looked up top
>> and saw this:
>>
>> pid user pr ni virt res shr s %CPU
>> %mem TIME+ command
>>
>> 659 root 20 0 20012 10m 476 R 98.2 23.5
>> 201:59:93 updatedb
>>
>>
>> I killed but it seems strange
>>
>> thank you
>
>
> You shouldn't be using your computer at 4:40am. Get some sleep. Its a cron
> job that's setup by default to update the slocate database. It basically
> lets you find files quickly. Try 'slocate xorg.conf' or if you want to
> find
> a fortune, try 'slocate fortune' =)
>
> Look at /var/spool/cron/crontabs if you want to change the time that the
> cron.daily runs.
>
> This is the script that was run when you got the "problem":
>
> $cat /etc/cron.daily/slocate
> #!/bin/sh
> /usr/bin/updatedb -c /etc/updatedb.conf
>
>
>
> Enjoy.
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>

well I finally managed to get rid of it
but It does not seem to be normal for updatedb to run eternally does it?

"Miguel De Anda" <miguel@thedeanda.com> ???????/???????? ? ????????
?????????: news:45fba028$0$20193$88260bb3@free.teranews.com.. .
> serge_moscou wrote:
>
>> hello
>>
>> today I found the remote system extremely slow.
>> I looked up top
>> and saw this:
>>
>> pid user pr ni virt res shr s %CPU
>> %mem TIME+ command
>>
>> 659 root 20 0 20012 10m 476 R 98.2 23.5
>> 201:59:93 updatedb
>>
>>
>> I killed but it seems strange
>>
>> thank you
>
>
> You shouldn't be using your computer at 4:40am. Get some sleep. Its a cron
> job that's setup by default to update the slocate database. It basically
> lets you find files quickly. Try 'slocate xorg.conf' or if you want to
> find
> a fortune, try 'slocate fortune' =)
>
> Look at /var/spool/cron/crontabs if you want to change the time that the
> cron.daily runs.
>
> This is the script that was run when you got the "problem":
>
> $cat /etc/cron.daily/slocate
> #!/bin/sh
> /usr/bin/updatedb -c /etc/updatedb.conf
>
>
>
> Enjoy.
>
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>

serge_moscou wrote:

> well I finally managed to get rid of it
> but It does not seem to be normal for updatedb to run eternally does it?
>
No. it isn't. I had it once, and it turned out to be a corrupted file
system. So I suggest you run an *fsck

serge_moscou a écrit :
> well I finally managed to get rid of it
> but It does not seem to be normal for updatedb to run eternally does it?
>
> "Miguel De Anda" <miguel@thedeanda.com> ???????/???????? ? ????????
> ?????????: news:45fba028$0$20193$88260bb3@free.teranews.com.. .
>> serge_moscou wrote:
>>
>>> hello
>>>
>>> today I found the remote system extremely slow.
>>> I looked up top
>>> and saw this:
>>>
>>> pid user pr ni virt res shr s %CPU
>>> %mem TIME+ command
>>>
>>> 659 root 20 0 20012 10m 476 R 98.2 23.5
>>> 201:59:93 updatedb
>>>
>>>
>>> I killed but it seems strange
>>>
>>> thank you
>>
>> You shouldn't be using your computer at 4:40am. Get some sleep. Its a cron
>> job that's setup by default to update the slocate database. It basically
>> lets you find files quickly. Try 'slocate xorg.conf' or if you want to
>> find
>> a fortune, try 'slocate fortune' =)
>>
>> Look at /var/spool/cron/crontabs if you want to change the time that the
>> cron.daily runs.
>>
>> This is the script that was run when you got the "problem":
>>
>> $cat /etc/cron.daily/slocate
>> #!/bin/sh
>> /usr/bin/updatedb -c /etc/updatedb.conf
>>
>>
>>
>> Enjoy.
>>
>>
>> --
>> Posted via a free Usenet account from http://www.teranews.com
>>
>
>
Hello,
perhaps a clue (I don't know the solution), updatedb catches some
special devices like /dev, /proc, /sys and it should not...
To kill definitely a process, use kill -9
Regards,
Thierry

On 2007-03-17, serge_moscou <serge_mtu@mtu-net.ru> wrote:
> and now to top it
> I 'm even unable to kill updatedb process
>
> I do:
>
> # kill 1044 (which updatedb pid)
>
> then
>
> # top or ps
>
> it is still there and running

First, please don't top-post.

As jjg mentioned, I'd suspect a bad filesystem or disk. Next time
you look at ps, look at the state of the process; if it's got a
D, it means the process is waiting on the disk, but unless you're
writing out large files processes are seldom in that state. If it
is it's a good sign something's wrong with the disk. (Of course,
updatedb *is* indexing the disk, so it being in D isn't necessarily
a bad thing. Being in D for three hours is probably bad.)

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

well ...ok I won't top-post:-) What is top-posting ?excuse me...

i looked ps and it indicates a mere R status (not D)

You have suggested a bad filsystem or disk.... Hm ...

Otherwise everything works fine .

Only when I launch updatedb it never stops ;-)) and uses 90% CPU, really.

is there a way to work out this problem?

Thank you



"Keith Keller" <kkeller-usenet@wombat.san-francisco.ca.us> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ
× ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:q3htc4xn6f.ln2@goaway.wombat.san-francisco.ca.us...
> On 2007-03-17, serge_moscou <serge_mtu@mtu-net.ru> wrote:
>> and now to top it
>> I 'm even unable to kill updatedb process
>>
>> I do:
>>
>> # kill 1044 (which updatedb pid)
>>
>> then
>>
>> # top or ps
>>
>> it is still there and running
>
> First, please don't top-post.
>
> As jjg mentioned, I'd suspect a bad filesystem or disk. Next time
> you look at ps, look at the state of the process; if it's got a
> D, it means the process is waiting on the disk, but unless you're
> writing out large files processes are seldom in that state. If it
> is it's a good sign something's wrong with the disk. (Of course,
> updatedb *is* indexing the disk, so it being in D isn't necessarily
> a bad thing. Being in D for three hours is probably bad.)
>
> --keith
>
> --
> kkeller-usenet@wombat.san-francisco.ca.us
> (try just my userid to email me)
> AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
> see X- headers for PGP signature information
>

On Sat, 17 Mar 2007 21:05:33 +0300, serge_moscou wrote:

Of course, since you were in a hurry :-)

> excuse me...

just like you did in the future line before

> well ...ok I won't top-post:-) What is top-posting ?


That's writing your answers before the questions, or
your Q before the A., simply speaking like a teen, always just
before the answers to your previous snoitseuq.

Puuref ;-)