Desativando com robustez cron específico. Script de hora em hora, diariamente, semanalmente

25

Em vários sistemas que administro, há scripts cron que são executados pelo /etc/cron.{hourly,daily,weekly}layout mais usado . O que eu quero saber é se existe alguma funcionalidade comum de 'desativar este script'.

Obviamente, simplesmente excluir algo de um determinado diretório o desativará, mas estou procurando uma solução mais permanente. A exclusão /etc/cron.daily/slocatefuncionará para desativar o noturno updatedbna minha máquina doméstica (onde nunca uso slocate), mas da próxima vez que atualizar o pacote slocate, tenho certeza de que ele reaparecerá.

As duas distribuições que mais me interessam são o Gentoo e o OpenSUSE, mas espero que exista um mecanismo amplamente implementado. Ambas as distribuições que eu tenho usam o vixie-cron (não tenho certeza se isso importa).

cron cron.daily

— benizi
fonte

45

Você deve poder chmod -x scriptnamedesativar um script, mas deixar o arquivo no lugar.

— Pausado até novo aviso.
fonte

5

Isso pode ou não ser desfeito pelo sistema de gerenciamento de pacotes. Você pode tornar isso mais robusto fazendo chattr +i scriptnamedepois do chmod.

— Mc0e 07/03

@ mc0e obrigado por me ensinar sobre arquivos imutáveis, mas como alguém disse uma vez , eles são assustadores . Se eu esquecesse o que fiz, isso poderia levar a problemas muito frustrantes.

— Jonathan Y.

2

@ JonathanY .: É lsattrpara isso - remover o assustador (ele lista os atributos de um arquivo).

— Pausado até novo aviso.

1

DW, claro, mas saber examinar os atributos do arquivo quando algo dá inexplicavelmente errado (como no tópico ao qual vinculei) é o verdadeiro pontapé aqui.

— Jonathan Y.

@JonathanY. Então agora você sabe. :-) De qualquer forma, acho que o bit 'assustador' em esse segmento ligado refere-se a um bug pacman, não chattr si

— mc0e

9

run-parts não executa tarefas com um ponto em seu nome, portanto

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

fará o truque.

— chrisv
fonte

1

Infelizmente, isso terá o mesmo problema ao atualizar o programa - ele verificará se o trabalho cron existe e, como não existe pelo nome original, será recriado.

— Jenny D diz Reinstate Monica

2

Voltar ao atualizar o programa é um efeito colateral da ferramenta de pacote em uso, não pode ser corrigido por meios simples e não é culpa do Cron. Alguns sistemas de pacotes destroem e pavimentam arquivos anteriores, outros diferenciam o novo e o antigo e perguntam se há alterações a serem revisadas. Independentemente disso, as atualizações que produzem comportamento não intencional devem ser uma parte frustrante, mas rotineira, da administração de sistemas unix neste momento. Existem simplesmente muitos pacotes movendo-se com muita rapidez para revisar regularmente todas as alterações em relação ao seu impacto em cada ambiente individual.

— 28414 peelman

No Debian, existe a noção de desvio de arquivo - ou seja, você pode renomear efetivamente o arquivo enquanto ele ainda é gerenciado pelo gerenciador de pacotes. Talvez exista um mecanismo semelhante no Gentoo e / ou no SUSE?

— Baixo

9

Geralmente cron.dailyé chamado /etc/crontabatravés de uma linha como por exemplo

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

man run-parts dá-lhe as opções.

run-parts --test /etc/cron.daily mostra quais trabalhos são executados sem executá-los.

Prefiro criar um subdiretório 'Desativado' e mudar meus trabalhos para lá.

De qualquer forma, se você atualizar um pacote, é provável que o trabalho volte ao lugar ou que os bits 'x' removidos sejam restaurados

— Pedro
fonte

1

Você pode remover o pacote slocate se nunca o usar.

— Maxfer
fonte

Isso foi apenas um exemplo, mas ainda é um bom conselho, obrigado. (Eu pensei que algo pode depender slocate, mas nada parece.)

— Benizi

Remova o slocate e instale o mlocate. Muito melhor.

— Mc0e 07/03

1

Se você usar cfengine ( https://cfengine.com/ ), poderá fazê-lo com desativar. Você acabou de escrever um arquivo de promessa para um grupo de hosts e ele se aplicará na próxima execução do cfagent. Fazer isso com fantoches ou chef ou qualquer outra coisa também deve ser bastante simples.

— natxo asenjo
fonte

Interessante. Eu encontrei apenas ferramentas de gerenciamento de configuração de maneira muito tangencial. Eu estava procurando uma solução geral "Eu tenho algum sistema arbitrário semelhante ao Unix".

— 11139 benizi

1

O /etc/cron.daily et. al. scripts são executados por um script chamado run-parts. Esse script varia. Por exemplo, a opção --test mencionada acima não está na máquina que estou usando neste instante.

Run-parts é um script bash. É uma ferramenta geralmente útil para executar todos os scripts no diretório fornecido como argumento. Geralmente é encontrado em / usr / bin / run-parts.

Ele tem um emaranhado de lógica para decidir o que executar. Esse código contém a resposta para sua pergunta, mas também varia. Então, você precisa ler o código para estar seguro.

Na versão que estou vendo, tem lógica que, ao trabalhar no diretório <foo>, verifique <foo> /jobs.deny. Se isso existir, ele se recusará a executar qualquer script mencionado nesse arquivo em uma linha, sozinho. Supondo que você tenha essa funcionalidade, é incrível porque continuará funcionando quando o pacote que instalar for instalado ou atualizado.

— Ben Hyde
fonte

0

Ao lidar com RHEL e derivados (que fornece o crontabspacote), você pode desativar explicitamente um trabalho colocando seu nome no jobs.denyarquivo.

Na página do manual crontabs / run-parts :

A execução de arquivos pode ser permitida ou negada criando o arquivo jobs.allow ou jobs.deny, que funcionou de maneira semelhante a outros arquivos de configuração de permissão / negação. O arquivo deve ser criado no diretório especificado.

O exemplo /etc/cron.daily/jobs.deny pode conter, por exemplo, 0logwatch, que proíbe a execução desse script.

— shodanshok
fonte

-1

Se você também não deseja o user-crontabs, desative o crond em sua lista de serviços.

No Debian e nas versões baseadas no Debian, isso é simplesmente uma questão de remover o link simbólico do /etc/rcX.d apropriado (para o nível de execução X).

Não sei como você lida com serviços no SUSE ou Gentoo.

— jishi
fonte

4

Isso é apenas uma má ideia. Desabilitar completamente o cron desabilitará tarefas de manutenção úteis, como rotação de log, atualizaçãob, possivelmente atualizações autônomas e backups padrão.

— Tobu

Updatedb é exatamente a tarefa que estou tentando desativar (atualiza o db para slocate). No entanto, sim, maus conselhos em geral.

— 11139 benizi

Oh, desculpe. Eu interpretei mal sua pergunta e achei que você queria desativar TODOS os cronjobs específicos do sistema, não um único.

— jishi