Desactivación robusta de la secuencia de comandos cron. {Hora, día, semana} específica

25

En varios sistemas que administro, hay scripts cron que se ejecutan a través del /etc/cron.{hourly,daily,weekly}diseño de uso común . Lo que quiero saber es si hay alguna funcionalidad común de 'deshabilitar este script'.

Obviamente, simplemente eliminar algo de un directorio dado lo deshabilitará, pero estoy buscando una solución más permanente. La eliminación /etc/cron.daily/slocatefuncionará para deshabilitar todas las noches updatedben mi máquina doméstica (donde nunca la uso slocate), pero la próxima vez que actualice el paquete Slocate, estoy bastante seguro de que volverá a aparecer.

Las dos distribuciones que más me interesan son Gentoo y OpenSUSE, pero espero que haya un mecanismo ampliamente implementado. Ambas distribuciones como las tengo usan vixie-cron (no estoy seguro de que importe).

cron cron.daily

— benizi
fuente

45

Debería poder chmod -x scriptnamedeshabilitar un script pero dejar el archivo en su lugar.

— Pausado hasta nuevo aviso.
fuente

55

El sistema de gestión de paquetes puede deshacer o no el proceso. Podrías hacer esto más robusto haciendo chattr +i scriptnamedespués de chmod.

— mc0e

@ mc0e gracias por enseñarme sobre archivos inmutables, pero como alguien dijo una vez , dan miedo . Si alguna vez olvido lo que hice, podría dar lugar a algunos problemas muy frustrantes.

— Jonathan Y.

2

@JonathanY .: Para eso lsattrestá: para eliminar el miedo (enumera los atributos de un archivo).

— Pausado hasta nuevo aviso.

1

DW seguro, pero saber mirar los atributos del archivo cuando algo sale inexplicablemente mal (al igual que en ese hilo al que me vinculé) es la verdadera patada aquí.

— Jonathan Y.

@JonathanY. Entonces ahora lo sabes. :-) En cualquier caso, creo que el bit 'aterrador' en ese hilo vinculado se refiere a un error de pacman, no al chat en sí mismo

— mc0e

9

run-parts no ejecuta trabajos que tienen un punto en su nombre, así que

mv /etc/cron.d/job /etc/cron.d/job.disabled

Hará el truco.

— chrisv
fuente

1

Desafortunadamente, tendrá el mismo problema al actualizar el programa: verificará si el trabajo cron existe y, dado que no existe por su nombre original, se volverá a crear.

— Jenny D dice Restablecer a Monica

2

Volver al actualizar el programa es un efecto secundario de la herramienta de paquete en uso, no se puede solucionar por medios simples y no es culpa de Cron. Algunos sistemas de paquetes destruyen y pavimentan archivos anteriores, otros difieren los nuevos y los antiguos y le avisan si hay cambios para revisar. En cualquier caso, las actualizaciones que producen un comportamiento no deseado deberían ser una parte frustrante, pero rutinaria, de la administración de sistemas Unix en este momento. Simplemente hay demasiados paquetes que se mueven demasiado rápido para revisar regularmente todos los cambios por su impacto en cada entorno individual.

— peelman

En Debian, existe la noción de un desvío de archivos , es decir, puede cambiar el nombre del archivo de manera efectiva mientras el administrador de paquetes todavía lo administra. ¿Quizás existe un mecanismo similar en Gentoo y / o SUSE?

— Bajo

9

Por cron.dailylo general, se invoca a /etc/crontabtravés de una línea como, por ejemplo,

run-parts --report /etc/cron.daily

man run-parts te da las opciones.

run-parts --test /etc/cron.daily muestra qué trabajos se ejecutan sin ejecutarlos.

Prefiero hacer un subdirectorio 'Desactivado' y mover mis trabajos allí.

En cualquier caso, si actualiza un paquete, es probable que el trabajo vuelva a su lugar o que los bits 'x' eliminados se restauren

— Peter
fuente

1

Puede eliminar el paquete slocate si nunca lo usa.

— Maxfer
fuente

Eso fue solo un ejemplo, pero sigue siendo un buen consejo, gracias. (Pensé que algo podría depender de la pendiente, pero nada parece).

— benizi

Elimine slocate e instale mlocate en su lugar. Mucho mejor.

— mc0e

1

Si usa cfengine ( https://cfengine.com/ ) podría hacerlo con deshabilitar. Simplemente escriba un archivo de promesa para un grupo de hosts y se aplicará en la próxima ejecución de cfagent. Hacer esto con títeres o chef o lo que sea también debería ser bastante simple.

— natxo asenjo
fuente

Interesante. Solo he encontrado herramientas de gestión de configuración de forma tangencial. Estaba buscando una solución general "Tengo un sistema arbitrario similar a Unix".

— benizi

1

El /etc/cron.daily et. Alabama. los guiones son ejecutados por un guión llamado run-parts. Ese guión varía. Por ejemplo, el interruptor --test mencionado anteriormente no está en la máquina que estoy usando en este instante.

Run-parts es un script bash. Es una herramienta generalmente útil para ejecutar todos los scripts en el directorio que se proporciona como argumento. Generalmente se encuentra en / usr / bin / run-parts.

Tiene una maraña de lógica para decidir qué ejecutar. Ese código contiene la respuesta a su pregunta, pero también varía. Por lo tanto, debe leer el código para estar seguro.

En la versión que estoy viendo, tiene una lógica que, cuando se trabaja en el directorio <foo>, busca <foo> /jobs.deny. Si eso existe, declina ejecutar cualquier script que se mencione en ese archivo en una línea, solo. Suponiendo que tenga esta funcionalidad, es increíble porque seguirá funcionando cuando el paquete que se instala se instala o actualiza.

— Ben Hyde
fuente

0

Si se trata de RHEL y derivados (que proporciona el crontabspaquete), puede deshabilitar explícitamente un trabajo al poner su nombre en el jobs.denyarchivo.

Desde la página del manual crontabs / run-parts :

La ejecución de archivos se puede permitir o denegar mediante la creación de archivos jobs.allow o jobs.deny que funcionaron de manera similar a otros archivos de configuración de permitir / denegar. El archivo debe crearse en el directorio especificado.

El ejemplo /etc/cron.daily/jobs.deny podría contener, por ejemplo, 0logwatch que prohíbe la ejecución de este script.

— shodanshok
fuente

-1

Si tampoco desea los crontabs de usuario, simplemente desactive crond en su lista de servicios.

En Debian y versiones basadas en Debian, esto es simplemente una cuestión de eliminar el enlace simbólico del /etc/rcX.d apropiado (para el nivel de ejecución X).

No sé cómo maneja los servicios en SUSE o Gentoo.

— jishi
fuente

44

Eso es solo una mala idea. Deshabilitar cron por completo deshabilitará tareas de mantenimiento útiles como logrotate, updatedb, posiblemente actualizaciones desatendidas y copias de seguridad estándar.

— Tobu

Updatedb es exactamente la tarea que estoy tratando de deshabilitar (actualiza el db para slocate). Sin embargo, sí, malos consejos en general.

— benizi

Oh, lo siento. Leí mal su pregunta y pensé que deseaba deshabilitar TODOS los cronjobs específicos del sistema, ni uno solo.

— jishi