Cron vs systemd timers

Recentemente, foi indicado para mim que existe uma alternativa ao cron, ou seja, temporizadores do systemd.

No entanto, não sei nada sobre temporizadores systemd ou systemd. Eu apenas usei cron.

Há uma pequena discussão no Arch Wiki . No entanto, estou procurando uma comparação detalhada entre crontemporizadores e sistemasd, com foco em prós e contras. Eu uso o Debian, mas gostaria de uma comparação geral para todos os sistemas para os quais essas duas alternativas estão disponíveis. Este conjunto pode incluir apenas distribuições Linux.

Aqui está o que eu sei.

Cron é muito velho, remonta ao final da década de 1970. O autor original do cron é Ken Thompson, o criador do Unix. O Vixie cron, dos quais os distribuidores modernos das distribuições Linux são descendentes diretos, data de 1987.

Systemd é muito mais recente e um tanto controverso. A Wikipedia me diz que seu lançamento inicial foi em 30 de março de 2010.

Portanto, minha lista atual de vantagens do cron sobre os temporizadores systemd é:

1. É garantido que o Cron esteja em qualquer sistema semelhante ao Unix, no sentido de ser um software de instalação suportado. Isso não vai mudar. Por outro lado, o systemd pode ou não permanecer nas distribuições Linux no futuro. É principalmente um sistema init e pode ser substituído por um sistema init diferente.

2. Cron é simples de usar. Definitivamente mais simples que os temporizadores systemd.

A lista correspondente de vantagens dos timers do systemd sobre o cron é:

1. Os temporizadores Systemd podem ser mais flexíveis e capazes. Mas eu gostaria de exemplos disso.

Então, para resumir, aqui estão algumas coisas que seria bom ver em uma resposta:

1. Uma comparação detalhada entre cron e systemd, incluindo prós e contras do uso de cada um.
2. Exemplos de coisas que um pode fazer e o outro não.
3. Pelo menos uma comparação lado a lado de um script cron versus um script de temporizadores do systemd.

Aqui estão alguns pontos sobre esses dois :

1. verificar o que seu trabalho cron realmente faz pode ser uma bagunça, mas todos os eventos do timer do systemd são cuidadosamente registrados no diário do systemd como as outras unidades systemd com base no evento que facilita as coisas.

2. Os temporizadores systemd são serviços systemd com todos os seus recursos para gerenciamento de recursos, programação de IO da CPU, ...
   Há uma lista:
   

   • filtros de chamada do sistema
     
   • IDs de usuário / grupo
     
   • controle de associação
     
   • bom valor
     
   • Pontuação OOM
     
   • Classe e prioridade de agendamento de E / S
     
   • Política de agendamento da CPU
     
   • afinidade umask
     
   • calças temporizador
     
   • bits seguros
     
   • acesso à rede e, ...
     

3. com a opção dependências, assim como outros serviços systemd, pode haver dependências no tempo de ativação.
   

4. As unidades podem ser ativadas de diferentes maneiras, também a combinação delas pode ser configurada. os serviços podem ser iniciados e acionados por diferentes eventos, como usuário, inicialização, alterações de estado do hardware ou, por exemplo, 5 minutos após a conexão de algum hardware e, ...

5. configuração muito mais fácil de alguns arquivos e tags diretas para fazer várias personalizações com base em suas necessidades com temporizadores do systemd.

6. Ative / desative facilmente a coisa toda com:

   systemctl enable/disable 
   

   e mate todos os filhos do trabalho com:

   systemctl start/stop
   

7. Os temporizadores systemd podem ser agendados com calendários e horários monotônicos, o que pode ser realmente útil em caso de fusos horários diferentes e, ...

8. eventos de hora do systemd (calendário) são mais precisos que o cron (parece 1s de precisão)

9. Os eventos de hora do sistema são mais significativos, para aqueles recorrentes ou mesmo para os que devem ocorrer uma vez, aqui está um exemplo do documento :

   Sat,Thu,Mon-Wed,Sat-Sun → Mon-Thu,Sat,Sun *-*-*00:00:00
     Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
                   Wed *-1 → Wed *-*-01 00:00:00
           Wed-Wed,Wed *-1 → Wed *-*-01 00:00:00
                Wed, 17:48 → Wed *-*-* 17:48:00 
   

10. Do ponto de vista de uso da CPU, o systemd timer ativa a CPU no tempo decorrido, mas o cron faz isso com mais frequência.

11. Eventos de timer podem ser agendados com base nos horários de término das execuções. Alguns atrasos podem ser definidos entre as execuções.

12. A comunicação com outros programas também é notável, às vezes é necessário que outros programas saibam os cronômetros e o estado de suas tarefas.

Direto da boca do cavalo, por assim dizer: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement

Um trecho da página acima:

Benefícios

Os principais benefícios do uso de temporizadores vêm de cada trabalho que possui seu próprio serviço de sistema. Alguns desses benefícios são:

• Os trabalhos podem ser facilmente iniciados independentemente de seus cronômetros. Isso simplifica a depuração.
• Cada trabalho pode ser configurado para ser executado em um ambiente específico (consulte systemd.exec (5)).
• Os trabalhos podem ser anexados aos cgroups.
• Os trabalhos podem ser configurados para depender de outras unidades do sistema.
• Os trabalhos são registrados no diário systemd para facilitar a depuração.

Ressalvas

Algumas coisas fáceis de fazer com o cron são difíceis de fazer apenas com as unidades de timer.

• Complexidade: para configurar um trabalho programado com o systemd, crie dois arquivos e execute alguns comandos systemctl. Compare isso com a adição de uma única linha a um crontab.
• E-mails: não há um equivalente interno ao MAILTO do cron para enviar e-mails em caso de falha no trabalho. Consulte a próxima seção para obter um exemplo de configuração de um equivalente usando OnFailure =.