Cron vs temporizadores systemd

Question

Foi recentemente apontado para mim que existe uma alternativa ao cron, a saber, temporizadores systemd.

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

Existe uma pequena discussão no Wiki do Arch . No entanto, estou procurando uma comparação detalhada entre os temporizadores cron e systemd, concentrando-se em vantagens e desvantagens. Eu uso Debian, mas eu 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 antigo, voltando ao final da década de 1970. O autor original do cron é Ken Thompson, o criador do Unix. Vixie cron, dos quais os crons nas distribuições modernas do Linux são descendentes diretos, data de 1987.

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

Então, minha lista atual de vantagens do cron sobre timers do systemd é:

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

2. O Cron é simples de usar. Definitivamente mais simples que os cronômetros systemd.

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

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

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

1. Uma comparação detalhada de temporizadores cron vs systemd, incluindo pros e contras de usar cada um.
2. Exemplos de coisas que alguém pode fazer que o outro não pode.
3. Pelo menos uma comparação lado-a-lado de um script cron versus um systemd script de temporizadores.

Answer 1

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 faz as coisas muito mais fácil.

2. Os temporizadores systemd são serviços systemd com todas as suas capacidades para gerenciamento de recursos, agendamento de CPU de IO, ...
   Existe uma lista:
   

   • filtros systemcall
     
   • IDs de usuário / grupo
     
   • membershipcontrols
     
   • bom valor
     
   • OOM score
     
   • classe e prioridade de agendamento de IO |
   • CPU de política de agendamento da CPU
     
   • afinidade umask
     
   • folgas temporizador
     
   • bits seguros
     
   • acesso à rede e ...
     

3. com a opção de 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 uma combinação de eles podem ser configurados. serviços podem ser iniciados e acionados por eventos diferentes, como usuário, inicialização, alterações de estado de hardware ou para exemplo 5mins depois de algum hardware ligado e, ...

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

6. Ative / desative facilmente tudo com:

   systemctl enable/disable 
   

   e mate todos os filhos do trabalho com:

   systemctl start/stop
   

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

8. eventos timed (calendário) são mais precisos que o cron (parece Precisão 1s)

9. eventos de tempo do systemd são mais significativos, para aqueles recorrentes ou mesmo aqueles 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. A partir do ponto de vista de uso da CPU, o temporizador systemd ativa a CPU no tempo decorrido, mas o cron faz isso com mais frequência.

11. Os eventos do timer podem ser agendados com base nos horários de término de execuções alguns atrasos podem ser definidos entre execuções.

12. A comunicação com outros programas também é notável é necessário que alguns outros programas conheçam temporizadores e o estado de suas tarefas.

Answer 2

Direto da boca do cavalo, por assim dizer: link

Um trecho da página acima:

Benefits

The main benefits of using timers come from each job having its own systemd service. Some of these benefits are:

• Jobs can be easily started independently of their timers. This simplifies debugging.
• Each job can be configured to run in a specific environment (see systemd.exec(5)).
• Jobs can be attached to cgroups.
• Jobs can be set up to depend on other systemd units.
• Jobs are logged in the systemd journal for easy debugging.

Caveats

Some things that are easy to do with cron are difficult to do with timer units alone.

• Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
• Emails: there is no built-in equivalent to cron's MAILTO for sending emails on job failure. See the next section for an example of setting up an equivalent using OnFailure=.