<Anterior | Conteúdo | Próxima>
É uma boa idéia escolher tempos de execução estranhos, porque os trabalhos do sistema são freqüentemente executados em horas "round", como você pode ver na Seção 4.4.4 a próxima seção. Por exemplo, as tarefas geralmente são executadas exatamente à 1 hora da manhã (por exemplo, indexação do sistema para atualizar um banco de dados de localização padrão), portanto, inserir a hora 0100 pode facilmente desacelerar o sistema em vez de ativá-lo. Para evitar que os trabalhos sejam executados ao mesmo tempo, você também pode usar o fornada comando, que enfileira processos e alimenta o trabalho na fila para o sistema de uma forma uniformemente equilibrada, evitando picos excessivos de uso de recursos do sistema. Consulte as páginas de informações para obter mais informações.
4.4.4. Cron e crontab
O sistema cron é gerenciado pelo cron daemon. Ele obtém informações sobre quais programas e quando devem ser executados a partir das entradas crontab do sistema e dos usuários. Apenas o usuário root tem acesso aos crontabs do sistema, enquanto cada usuário deve ter acesso apenas aos seus próprios crontabs. Em alguns sistemas (alguns) os usuários podem não ter acesso ao recurso cron.
Na inicialização do sistema, o cron daemon procura / var / spool / cron / para entradas crontab que são nomeadas após contas em / Etc / passwd, ele procura /etc/cron.d/ e procura / etc / crontab, então usa essas informações a cada minuto para verificar se há algo a ser feito. Ele executa comandos como o usuário que possui o arquivo crontab e envia por e-mail qualquer saída de comandos para o proprietário.
Em sistemas que usam o cron Vixie, as tarefas que ocorrem de hora em hora, diariamente, semanalmente e mensalmente são mantidas em diretórios separados em / Etc para manter uma visão geral, ao contrário da função cron padrão do UNIX, onde todas as tarefas são inseridas em um grande arquivo.
Exemplo de um arquivo crontab Vixie:
[root @ blob / etc] # mais crontab SHELL = / bin / bash PATH = / sbin: / bin: / usr / sbin: / usr / bin MAILTO = root
HOME = /
# peças de execução
# comandos para executar a cada hora
01 * * * * root run-parts /etc/cron.hourly
# comandos para executar todos os dias
02 4 * * * root run-parts /etc/cron.daily
# comandos para executar todas as semanas
22 4 * * 0 root run-parts /etc/cron.weekly comandos para executar todos os meses
42 4 1 * * root run-parts /etc/cron.monthly
[root @ blob / etc] # mais crontab SHELL = / bin / bash PATH = / sbin: / bin: / usr / sbin: / usr / bin MAILTO = root
HOME = /
# peças de execução
# comandos para executar a cada hora
01 * * * * root run-parts /etc/cron.hourly
# comandos para executar todos os dias
02 4 * * * root run-parts /etc/cron.daily
# comandos para executar todas as semanas
22 4 * * 0 root run-parts /etc/cron.weekly comandos para executar todos os meses
42 4 1 * * root run-parts /etc/cron.monthly
Alternative
Você também pode usar o crontab -l comando para exibir crontabs.
Algumas variáveis são definidas, e depois disso há o agendamento real, uma linha por trabalho, começando com 5 campos de hora e data. O primeiro campo contém os minutos (de 0 a 59), o segundo define a hora de execução (0-23), o terceiro é o dia do mês (1-31), depois o número do mês (1-12) , o último é o dia da semana (0-7, 0 e 7 são domingo). Um asterisco nesses campos representa o intervalo total aceitável para o campo. Listas são permitidas; para executar um trabalho de segunda a sexta-feira insira 1-5 no último campo, para executar um trabalho na segunda, quarta e sexta-feira insira 1,3,5.
Em seguida, vem o usuário que deve executar os processos listados na última coluna. O exemplo acima é de uma configuração Vixie cron em que o root executa o programa partes corridas em intervalos regulares, com os diretórios apropriados como opções. Nesses diretórios, os trabalhos reais a serem executados no horário agendado são armazenados como scripts de shell, como este pequeno script que é executado diariamente para atualizar o banco de dados usado pelo localizar comando:
billy @ ahost cron.daily] $ gato slocate.cron
# / Bin / sh
renice +19 -p $$> / dev / null 2> & 1
/ usr / bin / updatedb -f "nfs, smbfs, ncpfs, proc, devpts" -e \ "/ tmp, / var / tmp, / usr / tmp, / afs, / net"
billy @ ahost cron.daily] $ gato slocate.cron
# / Bin / sh
renice +19 -p $$> / dev / null 2> & 1
/ usr / bin / updatedb -f "nfs, smbfs, ncpfs, proc, devpts" -e \ "/ tmp, / var / tmp, / usr / tmp, / afs, / net"
Os usuários devem editar seus crontabs de forma segura usando o crontab -e comando. Isso impedirá que um usuário abra acidentalmente mais de uma cópia de seu arquivo crontab. O editor padrão é vi (consulte o Capítulo 6, mas você pode usar qualquer editor de texto, como gwim or gedit se você se sentir mais confortável com um editor de GUI.
Quando você sair, o sistema informará que um novo crontab está instalado.
Esta entrada do crontab lembra cassetete para ir ao seu clube desportivo todas as quintas-feiras à noite:
Billy: ~> crontab -l
# NÃO EDITE ESTE ARQUIVO - edite o master e reinstale.
# (/tmp/crontab.20264 instalado em Dom 20 de julho, 22:35:14 de 2003)
Billy: ~> crontab -l
# NÃO EDITE ESTE ARQUIVO - edite o master e reinstale.
# (/tmp/crontab.20264 instalado em Dom 20 de julho, 22:35:14 de 2003)
# (Versão Cron - $ Id: chap4.xml, v 1.28 2007/09/19 12:22:26 tille Exp $)
38 16 * * 3 e-mails -s "noite de esportes" Billy
# (Versão Cron - $ Id: chap4.xml, v 1.28 2007/09/19 12:22:26 tille Exp $)
38 16 * * 3 e-mails -s "noite de esportes" Billy
Depois de adicionar uma nova tarefa agendada, o sistema informará que um novo crontab está instalado. Você não precisa reiniciar o cron daemon para que as alterações tenham efeito. No exemplo, cassetete adicionou uma nova linha apontando para um script de backup:
Billy: ~> crontab -e
45 15 * * 3 e-mails -s "noite de esportes" Billy
4 4 * * 4,7 /home/billy/bin/backup.sh
<- escrever e sair ->
crontab: instalando novo crontab billy: ~>
Billy: ~> crontab -e
45 15 * * 3 e-mails -s "noite de esportes" Billy
4 4 * * 4,7 /home/billy/bin/backup.sh
<- escrever e sair ->
crontab: instalando novo crontab billy: ~>
O backup.sh o script é executado todas as quintas e domingos. Veja a Seção 7.2.5 para uma introdução ao script de shell. Lembre-se de que a saída dos comandos, se houver, é enviada ao proprietário do arquivo crontab. Se nenhum serviço de e-mail estiver configurado, você pode encontrar a saída de seus comandos em sua caixa de correio local,
/ var / spool / mail / , um arquivo de texto simples.