Qual é a vantagem de usar um script bash para tarefas agendadas?

1

Pelo que entendi, você pode escrever seus crons editando

crontab -e

Eu encontrei várias fontes que, em vez disso, se referem a um script bash no cron job, em vez de escrever uma linha de trabalho para linha.

O único benefício é que você pode consolidar muitas tarefas em uma tarefa do cron usando um script bash?

Pergunta adicional para um novato: Editar crontab -e se refere a um arquivo correto? Notei que se eu abrir o crontab -e e fechar sem editar, quando eu abrir o arquivo novamente, há uma extensão numérica diferente, como:

"/tmp/crontab.XXXXk1DEaM" 0L, 0C

Eu acho que o crontab está armazenado em / var / spool / cron ou / etc / crontab ??

Por que ele armazenaria o cron na pasta tmp?

    
por AlxVallejo 09.04.2012 / 21:58

2 respostas

7

Depende do que você está fazendo com o trabalho.

O cron não fornece um ambiente de script real, portanto, se você estiver fazendo algo mais complicado do que simplesmente chamar alguns comandos, provavelmente desejará usar o cron para chamar um script. Você também pode lidar com coisas como expansão de variáveis em um script, o que pode ser difícil, se não impossível, no ambiente do cron.

O arquivo temporário que você vê quando executa crontab -e é exatamente isso: um arquivo temporário que será limpo depois que você sair da sessão do editor. Os crontabs reais que você edita através deste método acabam em / var / spool / cron.

Na verdade, uma vez que estas são questões relativamente básicas específicas de unix, há o lado unix.stackexchange.com das coisas, que pode ser mais útil.

    
por 09.04.2012 / 22:02
5

Ok, então, para a primeira pergunta: há algumas razões para usar um script bash para seu cronjob:

Como você mencionou, você pode consolidar muitos comandos em um script bash. Isso é muito mais legível do que apenas agrupar uma enorme linha de crontab, especialmente porque o fluxo lógico é mais óbvio. Comparar:

command1 >/tmp/foo && command2 || command3

vs.

if command1 >/tmp/foo
then
  command2
else
  command3
fi

Outro motivo para chamar um script no seu crontab é para que você possa chamar algo além do bash. Por exemplo, você pode invocar um script perl ou até mesmo um script php.

Além disso, suponha que você tenha alguma lógica que você queira chamar fora do cron. Então, também faz sentido colocar essa lógica em um script separado instalado em seu servidor. Você pode executar esse script conforme necessário na linha de comando e também pode chamá-lo no crontab.

Finalmente, note que citar em crontabs é realmente estranho. O exemplo canônico é que crontabs comem o sinal de porcentagem. Se você colocar um '%' em uma linha crontab, você realmente terá que dobrá-lo ('%%') ou então o cron irá comer o sinal de porcentagem e confundir o jebebus de você.

Basicamente, envolver um cronjob em um script é mais seguro (mais citar / escapar padrão) e mais flexível. Qualquer cronagem mais longa que um ou dois comandos provavelmente deve ser movida para um script separado.

A segunda pergunta é bem direta: quando você edita seu crontab, não edita o arquivo em / var / spool diretamente. Em vez disso, o comando crontab -e copia seu arquivo crontab para um arquivo temporário em / tmp. Parte do nome tempfile é uma string aleatória projetada para diminuir a chance de duas invocações de crontab -e de tentar editar o mesmo arquivo em / tmp.

É mais seguro editar um arquivo temporário por vários motivos. Uma é que, se o processo de edição falhar, o arquivo original ficará intocado e utilizável. Outra é que ele permite que o sistema verifique o novo crontab em busca de erros de sintaxe antes de substituir o antigo.

Além disso, ficarei surpreso se consegui digitar toda essa entrada sem dizer cornjob uma vez.

    
por 10.04.2012 / 00:47

Tags