On Tue, 18 Feb 2003, Santiago Vila wrote: > hector debian escribió: > > maté el proceso en el top y luego comenté todas las líneas del archivo > > /etc/cron.daily/find (donde había un updatedb) con eso creo que se arreglo. > > Felicidades, acabas de estropear la orden "locate" de tu sistema.
No necesariamente. Una persona consciente de lo que hace puede desear hacer updatedb manualmente de vez en cuando. Por otra parte imagina que en el momendo que se activa la tarea updatedb tienes un dispositivo removible cualquiera montado y lleno de ficheros. Te hace la gracia de meterte un montón de información seguramente inutil en esa BD de ficheros. Yo he alterado un poco las cosas y lo ejecuto como tarea un par de veces por semana. He añadido un cron.2_weekly y he colocado las horas de forma que esas tareas no me incomoden tanto como antes pero continua incomodándome. Por si a alguien le interesa paso mi /etc/crontab SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # (mon = 3,6 = Miercoles,Sabado) # m h dom mon dow user command 55 8 * * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily 0 9 * * 3,6 root test -e /usr/sbin/anacron || run-parts --report /etc/cron.2_weekly 0 9 * * 7 root test -e /usr/sbin/anacron || run-parts --report /etc/cron.weekly 10 9 1 * * root test -e /usr/sbin/anacron || run-parts --report /etc/cron.monthly # Lo que estaría bien es que el sistema de gestión de prioridad de ejecución de procesos hiciera que los procesos poco prioritarios consumieran mucho menos recursos que los procesos con prioridad más alta pero yo creo que esto se nota demasiado poco. No me refiero solo a usar un parche para que el kernel sea preentivo (o como si diga en español). Eso solo mejora la catastrófica situación en que quedan normalmente los procesos interactivos cuando el sistema esta sobrecargado. Me refiero a que updatedb es una tarea que tarda unos pocos minutos pero no tendría ninguna importancia si ese proceso y otros muchos de mantenimiento del sistema tardaran diez o veinte veces más con tal de no hacer ni el menor estorbo. Una cosa que se puede hacer es mandar a esos procesos una señal SIGSTOP (kill -19) para detenerlos y una señal SIGCONT (kill -18) para reanudarlos a conveniencia, pero es una chapuza incomoda si hay que hacerlo manualmente. Un proceso detenido no libera todos los recursos pero si libera memoria, CPU, y entrada/salida que son los que generalmente los entran en deficit. Lo ideal sería hacer una especie de supernice capaz de lanzar procesos que se detengan y que se reactiven siguiendo una política que permita dosificar el nivel de carga del sistema. -- Un saludo Antonio Castro /\ /\ Ciberdroide Informática \\W// << http://www.ciberdroide.com >> _|0 0|_ +-oOOO-(___o___)-OOOo---------------------+ | . . . . U U . Antonio Castro Snurmacher | | . . . . . . . [EMAIL PROTECTED] | +()()()---------()()()--------------------+