¿Puedo deshabilitar updatedb?

¿Es updatedbnecesario en absoluto? Nunca uso locatey mis servidores tienden a tener docenas de millones de archivos, lo que generalmente hace que la actualizaciónb se ejecute durante mucho tiempo y consuma las E / S que necesita MySQL u otro software.

¿Puedo eliminarlo de cron y esperar que todo funcione? (por todo lo que quiero decir me refiero al software habitual que se encuentra en el servidor: linux, cpanel, mysql, apache, php, etc.).

Sí, puede deshabilitarlo en los crons o eliminar el paquete que proporciona updatedb. En un sistema Red Hat, seguiría los pasos para determinar si algo lo requiere antes de la eliminación.

1. Primero averigüe dónde se encuentra el programa en el disco.

   $ type updatedb
   updatedb is /usr/bin/updatedb
   

2. A continuación, averigüe qué paquete proporciona updatedb.

   $ rpm -qf /usr/bin/updatedb
   mlocate-0.26-3.fc19.x86_64
   

3. A ver si algo lo requiere mlocate.

   $ rpm -q --whatrequires mlocate
   no package requires mlocate
   

4. Nada lo requiere para que pueda eliminar el paquete.

   $ yum remove mlocate
   

Puede deshabilitar el escaneo de directorios que tienen muchos archivos ( /var/wwwpor ejemplo) editando el /etc/updatedb.confarchivo de configuración. Si realmente desea deshabilitarlo, simplemente elimine el cronjob.

Elimínelo usando su administrador de paquetes, si otro paquete lo usa, lo sabrá, ya que tiene que depender de él (dependencia del paquete).

Tengo un servidor con Nginx, php-fpmy mysql, y funciona muy bien sin updatedb.

No voy a llegar muy lejos diciendo esto, pero lo más probable es que no esté actualizadob que está causando sus problemas. Probablemente algo más que no desee, ya sea una aplicación de respaldo que no haya configurado a su gusto o algún problema de seguridad con su perfil / estructura de grupo de sistemas.

Otro caso en el que parecería que la asignación de memoria de los sistemas está funcionando en contra del usuario es el escenario cuando uno 'desconoce los sistemas de archivos virtuales de apilamiento'. Y eso es un problema del problema. Una 'bomba virtual de mala lógica', por así decirlo.

Sucede con bastante frecuencia en unidades USB formateadas en fat32 en un sistema ext 4 que luego se transfieren a sistemas zfs que están configurados incorrectamente con el shell csh como el shell de inicio de sesión de man. Crea la recurrencia virtual del problema "Sistema de archivos USB de solo lectura" en el disco y formatea / monta la unidad en vFat desde fat32, lo que a su vez crea un sector de bloques defectuosos y extrae (prácticamente mueve) un directorio hasta su nivel de directorios padre, lo que provoca el bucle infinito! El directorio no está físicamente en el nivel de jerarquía de los padres. La sintaxis de las causas csh es la causa de esto. * NOTA: La unidad se lee solo en todos los sistemas, excepto en un sistema de inicio de sesión zfs c-shell.

Desactivar completamente la actualización b podría crear una lógica errónea en referencia a la asignación de memoria y al "efecto de retroceso". Si alguna vez ha tenido un retroceso cuando no lo quería, ya sabe a qué me refiero cuando dos horas de línea de comando las secuencias de comandos están Fubar-ed porque no asignó su procesamiento de trabajo a la memoria.

Ahora, si tiene dos o más procesadores físicos (por ejemplo, doble núcleo o más), y ddr3 ram, entonces está bien. Siempre y cuando no esté ejecutando gráficos pesados, en cuyo caso si esa carga de energía está causando sus problemas, updatedb sería el último en su lista. Si está intentando ocultar sus movimientos al sistema por alguna razón, entonces hay otras formas de hacerlo en lugar de deshabilitar updatedb, y de hecho updatedb solidificaría sus acciones de que 'nada sucedería' en lo que respecta al disfraz de su sistema.

Bastante francamente basado en el tamaño del archivo binario / usr / bin / updatedb y considerando la arquitectura de la comunicación de señal / sistema con el sistema operativo y que Bash es 10 veces el tamaño de un guión de shell o ceniza que la llamada asincrónica es Muy barato en el sistema.

Si ha iniciado sesión en el shell ejecutando secuencias de comandos secuenciales que ha escrito, y es un administrador (por ejemplo, sudo), ejecuta el siguiente comando:

~$ sudo bash
:~# ./script.sh

Entonces, probablemente desee crear una variable local dentro de su script (updatedb necesita privilegios del sistema, también conocido como root / sudo / wheel), por ejemplo:

#! /bin/sh
# Create local variables
UPD="updatedb"

echo "Beginning Execution of sequence "

En cuyo caso, la secuencia está utilizando STDOUT / STDIN de otros scripts de shell que ha escrito y está ejecutando como variables con su script principal o dice que tiene un paquete de administración personal o comercial configurado donde carga / descarga / puerto desde cdrom o usb o lo que sea, que es extremadamente grande y tiene scripts de instalación personal para ellos, QUIERES MANTENER actualizadob. Cuando el terminal shell está abierto, esa es su instancia de aplicación principal. Otras aplicaciones pueden ejecutarse de manera asíncrona pero actualizadasb es una de las menos costosas en términos de demanda general de sistema / computación. Muchas veces, especialmente con el lxdm Desk Enviro's y el Lxterm (esa cosa es súper rápida), pero no solo; sin agregar updatedb a mis scripts, el sistema me ha disparado errores de que los archivos no existen o que algo malo había sucedido. Y me gusta lo que!

El shell es más rápido que el sistema que administra. ¡Te lo garantizo!

En ese caso, llamaría a la variable updatedb para bloquear la secuencia anterior en la memoria, como se muestra

echo "Updating local database "

$UPD

echo "Exiting script two "

exit

¿Ves lo que estoy diciendo? Si pregunta esto porque está ejecutando pruebas de velocidad de ejecución, es decir, el estilo Andrew Tanenbaum que tiene. De lo contrario, use la herramienta para su ventaja.

Por lo menos en Arch Linux, parece que man-db.timery updatedb.timerestán habilitadas por defecto (es decir: los siguientes archivos existen), pero no existe no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. [...](salida systemctl enable {man-,update}db.timer).

Estos son los enlaces simbólicos que están presentes en el sistema de archivos:
/usr/lib/systemd/system/multi-user.target.wants/man-db.timer
/usr/lib/systemd/system/multi-user.target.wants/updatedb.timer

Debería ser cuestión de simplemente eliminarlos.
Sin embargo, ellos pueden volver a crear en cada re / instalación / actualización de man-db, mlocatepaquetes, respectivamente.

Para ArchLinux, una posible solución es tener un gancho para que pacman los elimine.
Sin embargo, los eliminaría en cada uno de estos eventos, incluso si desea que estén habilitados en las actualizaciones.
En ese caso, podría deshabilitar el gancho cuando desee habilitar el temporizador.
Pero, habilitar el temporizador surtirá efecto solo en la re / instalación / actualización del paquete, ya que no hay una sección configurada en los .timerarchivos de la unidad predeterminada para systemctl enabledirigir directamente los temporizadores.
Se necesitaría un manual ln -s ../man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timero ln -s ../updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timercomando para habilitar el temporizador / s, y eliminar el / los enlace / s para deshabilitarlos.

Podría tener que anular las unidades personalizadas /etc/systemd/system/{man-,update}db.timer, que se proporcionan WantedBy=multi-user.targeten la [Install]sección para permitir systemtl enable|disable, pero los enlaces /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timeraún se crearían en re / instalación / actualización, volviendo a habilitar efectivamente el .timers.

También puedes correr systemctl mask man-db.timer updatedb.timerpara enmascarar los temporizadores.
Incluso si aún fuera posible ejecutar manualmente systemctl start man-db.service updatedb.servicepara iniciar los servicios correspondientes, no podría iniciar manualmente los temporizadores, por cualquier razón el usuario se encontraría con ganas / necesidad de hacerlo.
Esta solución alternativa no permite tener /etc/systemd/system/{man-,update}db.timerpresentes archivos de unidad personalizados anulados si se desea / necesita, ya que systemd debe reemplazarlos con un enlace simbólico /dev/nullpara indicar una unidad enmascarada.

El enmascaramiento parece ser la solución menos intrusiva.
Prefiero eliminar manualmente /usr/lib/systemd/system/multi-user.target.wants/{man-,update}db.timerdespués de cada actualización, y tener archivos de unidad de anulación que /etc/systemd/system/{man-,update}db.timertienen una [Install]sección WantedBy=multi-user.targetpara habilitar la systemctlhabilitación / deshabilitación manual .

Desafortunadamente, no hay una solución simple para esto, que al menos, se me ocurra, en este momento.
Esto supone que los paquetes man-db, mlocateson buscados / necesario para mantenerse instalado en el sistema: la eliminación de ellos no serían una solución deseada / utilidad.

También vea esto: https://www.reddit.com/r/archlinux/comments/36fqzh/updatedbservice_and_mandbservice_increases_boot/