Cron de próxima geração com systemd Criando um cronômetro

Você precisa agendar alguma tarefa no futuro em seu computador? Isso pode parecer simples - afinal, sua máquina de lavar louça é capaz de esperar antes de iniciar com a ajuda de um botão - mas às vezes os computadores estão fazendo tarefas tão simples tão difícil.Mas se você tem alguma experiência, provavelmente já ouviu falar cron, este software totalmente dedicado a lançar a tarefa certa no momento certo. Mas esta ferramenta foi realmente projetada com a simplicidade em mente e você pode no final ter surpresas ruins.Se você alguma vez conseguiu agendar uma tarefa no Windows, você usou o Planejador de Tarefas do Windows. Ele tem uma GUI por padrão, mas também não o torna tão simples de usar: esses dois sistemas apenas iniciam um processo em uma data e hora fixas.

Para entender como o systemd pode ser útil para você, vou dar um exemplo.

Quais armadilhas os temporizadores do systemd evitarão você?

Se você já teve uma máquina com dados de seu interesse, você vai querer ter uma cópia de seus dados em outro lugar, provavelmente mais seguro. Se você gerencia um servidor, é obrigatório: afinal, como você vai se recuperar se o seu disco rígido falhar e impedir que você recupere quaisquer dados??

Então, como uma pessoa responsável, você configura o backup todas as semanas ou todos os dias. Você pode configurá-lo usando o cron, agende-o para 4h24, mas aqui começa o problema: e se o seu servidor for desligado das 4h10 às 4h30 por qualquer motivo?

Bem, é provável que o cron simplesmente ignore esse backup. Isso pode ser crítico se isso acontecer com frequência e silenciosamente ou se seu código depender do fato de ser executado e puder falhar de outra forma. Geralmente, isso acontece quando você configura uma tarefa de limpeza via cron e não inicia. De repente, o seu código pode não ter espaço suficiente para continuar e vai quebrar - é uma situação tão triste, certo Sr. Elton John.

No entanto, se um lançamento perdido pode ser um problema, imagine um segundo - nossa, John Lennon agora? - que sua tarefa é muito lenta. Se sua tarefa está configurada para ser executada a cada 10 minutos, mas leva 15 minutos para ser concluída, o cron ou o Windows iniciará outra tarefa felizmente, mesmo que a tarefa atual ainda não tenha terminado - e assim, você terá 2 instâncias de sua tarefa em execução simultaneamente , qual é o receita perfeita para desastre. Quando um programa está sendo executado simultaneamente, mas não foi projetado para isso, é muito provável que ele corrompa arquivos, outros softwares, bancos de dados - e seu servidor se torna repentinamente um navio afundando como o Titanic.

OK, talvez eu esteja indo longe demais com o Titanic, mas você entendeu. Embora o systemd não pudesse ter feito muito para salvar este navio, ele pode ajudá-lo com todas essas deficiências e garantir a você férias de Natal mais longas, graças aos insetos que irá evitar. Agora é hora de saber como configurar temporizadores systemd.

Como agendar backup de servidor automatizado?

Em primeiro lugar, os temporizadores do systemd acionam um serviço do systemd, portanto, antes de agendar sua tarefa, você precisa primeiro torná-la um serviço. Felizmente, escrevi um guia para criar o serviço systemd, desta forma ele apresentará a maneira de trabalhar do systemd. Você deve ler antes de continuar. A menos que você exatamente sabe o que você está fazendo, seu arquivo de serviço systemd deve não conter qualquer configuração WantedBy =. Se você deseja iniciar seu serviço em um momento específico, provavelmente não deseja iniciá-lo na inicialização.

Graças ao sistema de serviço systemd, é impossível ter várias instâncias de sua tarefa em execução por engano: se uma tarefa já estiver em execução, ela simplesmente ignorará a inicialização e deixará a tarefa atualmente em execução terminar seu trabalho.

Assim que tiver um serviço systemd para agendar, crie um arquivo com o mesmo nome do seu serviço, exceto que deve terminar com .cronômetro em vez de .serviço. Em nosso exemplo de backup automatizado, o serviço seria backup automatizado.serviço e o cronômetro seriam automatizados - backup.cronômetro. Ambos os arquivos devem estar no mesmo diretório. Como eu disse a você no artigo de serviço do systemd, recomendo que você escreva esses arquivos em um local normal, como seu diretório inicial e, em seguida, copie-os para uma pasta do systemd, depois de terminar suas edições.

Então, deixe-me mostrar como é o nosso arquivo de cronômetro:

[Unidade]
Descrição = Agendar backups fora do horário de pico
[Cronômetro]
OnCalendar = * - * - * 03:00:00
RandomizedDelaySec = 7200
Persistente = verdadeiro
[Instalar]
WantedBy = temporizadores.alvo

Assim como nos serviços systemd, há 3 seções. [Unit] ou [Install] funcionam exatamente da mesma forma explicada no meu artigo de serviços do systemd. Observe que WantedBy = é importante aqui porque os cronômetros podem ser iniciados ou parados, então se você não disser ao systemd para iniciar o cronômetro durante a inicialização, ele nunca irá disparar. cronômetros.o alvo é um alvo especial do systemd para temporizadores.

Agora, a seção [Timer]. Dentro dele, você encontrará todas as configurações relacionadas a quando o cronômetro deve ser acionado. Para nosso backup automatizado, pedi ao systemd para executá-lo entre 3h e 5h no fuso horário do servidor. A hora exata é aleatória a cada dia.

OnCalendar = define o cronômetro relacionado ao horário do seu servidor (relógio de parede), como todos os domingos às 13h. Se você já usou o cron anteriormente, deve estar realmente familiarizado com esta sintaxe. No entanto, tem alguns benefícios adicionais.

Por exemplo, se quiser que algo aconteça a cada hora, você pode fazer assim:

OnCalendar = hora

e diariamente:

OnCalendar = diário

Na verdade, ele suporta todos os seguintes valores:

1. minuciosamente
2. de hora em hora
3. diariamente
4. por mês
5. semanalmente
6. anual
7. trimestral
8. semi anualmente

No entanto, há um problema com essas palavras-chave: por exemplo, dispara diariamente à meia-noite, que geralmente é um horário de pico em sistemas de computação. É por isso que é recomendado usar RandomizedDelaySec = (seu uso é especificado abaixo). De qualquer forma, para backup não é uma boa opção: meia-noite não é fora do horário de pico, é o contrário. Portanto, precisamos definir com mais precisão quando queremos ver essa tarefa lançada.

Se você quiser mais controle, pode escrever uma data como 06-12-2018 12:49:37. Bem, se você for tão específico, você apenas acionará o cronômetro uma vez. Para torná-lo recorrente, você substituirá qualquer um desses elementos por * asterisco.

OnCalendar = * - * - * 03:00:00

Como você pode ver acima, em nosso exemplo de backup, toda a parte da data é * - * - *, o que significa que deve ocorrer todos os dias de cada mês de cada ano. Agora, se você fizer:

OnCalendar = * - 12-25 03:00:00

Em seguida, é executado a cada 25 de dezembro às 3h. Cronômetro systemd perfeito para o Papai Noel - mesmo se eu duvidar que ele vá precisar de um! Então o asterisco adiciona recorrência onde você o coloca. Se você colocar no campo ano, significa "todos os anos", etc.

Finalmente, você pode adicionar UTC no final da linha para usar a hora UTC em vez do fuso horário local. Por exemplo, alguns serviços redefinem suas cotas de API à meia-noite, mas para evitar qualquer desvio de fuso horário, ele usa UTC. Portanto, para essas tarefas, você faria:

OnCalendar = UTC diário

Agora, vamos resolver outro problema: horas de ponta. systemd também tem uma configuração para lutar contra isso.

RandomizedDelaySec = permite atrasar a tarefa por um período de tempo aleatório. O valor é o número máximo de segundos que o cronômetro irá atrasar. Destina-se especificamente a tais casos. Você se lembra que no systemd, diariamente sempre dispara à meia-noite? Bem, semanalmente sempre dispara à meia-noite de segunda-feira, e anualmente dispara à meia-noite de 1º de janeiro, um dos piores picos do ano com interrupções de rede em todos os lugares. Você certamente não quer que isso aconteça.

Ao adicionar um atraso, você remove esse problema: ele atrasará automaticamente em um momento desconhecido sua tarefa. Aleatoriedade aqui é importante porque é muito mais provável que seja mesmo quando é aleatório e uma carga uniforme permite otimizar melhor suas tarefas.

Digamos que você precise executar suas tarefas por volta das 7h da manhã, mas deseja permitir um pequeno atraso de no máximo 15 minutos, você faria assim:

RandomizedDelaySec = 900

Isso deve ser o suficiente para atrasos. Às vezes, atrasos de até milissegundos são suficientes para evitar picos indesejados.

Persistente = cuida dos gatilhos perdidos do cronômetro. E se o seu servidor for desligado durante a noite? Bem, o backup nunca seria acionado. Configurá-lo como verdadeiro permite que o system o execute na próxima inicialização em tais casos. Desta forma, você sabe de uma forma ou de outra, a tarefa do temporizador será executada. Seu uso é simples, basta fazer isso:

Persistente = verdadeiro

No entanto, isso tem uma desvantagem que é realmente difícil de evitar: quando várias tarefas de diferentes temporizadores são perdidas, todas elas são executadas na inicialização e tornam a inicialização mais lenta. Na minha opinião isso é muito melhor do que se nunca rodar e afinal isso é normal, o momento mais apropriado para rodar o cronômetro é quando ele está programado, depois provavelmente será inapropriado de qualquer maneira.

OnBootSec = é a última opção que vou mostrar a você (mas não menos importante). É se você deseja acionar um cronômetro algum tempo após a inicialização, em vez de com base no calendário. Por exemplo, se você precisar verificar na inicialização se o seu servidor foi iniciado corretamente e funcionando como pretendido, você pode escrever um serviço de verificação e usar a configuração do temporizador para acioná-lo depois que o sistema teve tempo suficiente para inicializar.

Digamos que o sistema precise de 3 minutos para inicializar, você pode fazer:

OnBootSec = 180

E apesar do nome, você também pode fazer:

OnBootSec = 3 minutos

Se você precisar OnBootSec = e OnCalendar =, ele iniciará o serviço sempre que qualquer um desses 2 eventos acontecer.

Ok, agora é hora de salvar seu arquivo, copie-o para a pasta do sistema se você seguiu meu conselho acima e teste se seu cronômetro está funcionando corretamente.

Habilite seu novo cronômetro e monitoramento

Para testar seu novo temporizador, você deve informar ao systemd que adicionou um novo temporizador, então você precisa digitar este comando:

$ sudo systemctl daemon-reload

Agora, o systemd levará em consideração seu novo cronômetro e observará de perto quando executar sua tarefa. Como o systemd está sempre em execução, ele é, afinal, um dos melhores candidatos para gerenciar e executar suas tarefas agendadas.

Uma coisa que você pode achar contra-intuitivo: um cronômetro é por padrão desabilitado. Para habilitá-lo, você precisa fazer este comando:

$ sudo systemctl enable --now automatic-backup.cronômetro

Você provavelmente desejará ver se seu cronômetro funciona conforme o esperado. Boas notícias: o systemd é gentil o suficiente para ter um comando informando quando foi lançado pela última vez e quando o próximo lançamento está agendado (exceto se o temporizador estiver configurado para rodar apenas na inicialização, já que o systemd não sabe quando o sistema irá inicializar novamente, obviamente). Este é o comando:

$ systemctl status backup automatizado.cronômetro

Finalmente, quando não precisar mais do cronômetro, você também pode desativá-lo:

$ sudo systemctl disable --now automatic-backup.cronômetro

Conclusão

Usando cronômetros do systemd, seu gerenciamento de tarefas agendadas está em um próximo nível: honestamente, eu pessoalmente sinto que as tarefas agendadas deveriam ter sido assim há anos.

Oh, uma pequena surpresa para você: todos os temporizadores do systemd são registrados em um sistema bem estruturado com filtragem, rotação de log e tudo o mais. Então, eu convido você a ver como você pode ver os registros sobre suas tarefas programadas!