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 é:
É 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.
Cron é simples de usar. Definitivamente mais simples que os temporizadores systemd.
A lista correspondente de vantagens dos timers do systemd sobre o cron é:
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:
Uma comparação detalhada entre cron e systemd, incluindo prós e contras do uso de cada um.
Exemplos de coisas que um pode fazer e o outro não.
Pelo menos uma comparação lado a lado de um script cron versus um script de temporizadores do systemd.
"O Cron está garantido em qualquer sistema semelhante ao Unix. Isso não vai mudar." - Eu debateria isso fortemente. Embora historicamente o cron tenha sido frequentemente incluído na configuração básica das instalações do Unix, na maioria dos sistemas hoje em dia é simplesmente um pacote de software opcional arbitrário, entre outros. De fato, existem várias alternativas populares de cron (por exemplo, anacron, fcron, jobber) que podem ser preferíveis ao cron. A funcionalidade do cron não é essencial para a operação de um sistema da mesma maneira que systemd ou init, portanto, se você estiver preocupado com a portabilidade atual e futura, prefiro não apostar nela.
Essa é uma lista bastante das coisas que você deseja em uma resposta. Acho que talvez você deva dedicar algum tempo aprendendo as ferramentas e veja se consegue formular essas respostas por conta própria e, se tiver coisas específicas que não entende, pergunte aqui.
— Larsks #
Na verdade não. Eu disse tudo o que quero dizer sobre o assunto. Entrar em uma discussão extensa sobre qualquer coisa que envolva systemd é pior do que inútil - alguns pensam que os pequenos benefícios que o systemd traz valem a monopólio corporativo do ecossistema linux. Outros não.
— 24516
"Cron é muito velho, remonta ao final dos anos 1970". Factualmente correto, mas completamente irrelevante, desde que os pacotes em seu sistema sejam mantidos de maneira sensata e estável. O sol também é muito antigo, mas espero que isso não signifique que devamos substituí-lo por algo mais brilhante e mais novo.
— Otheus
@Otheus, acho que você está errando essa parte - dizer que algo existe há muito tempo não é um insulto. Pelo menos para muitas pessoas do Unix. É mais como dizer que uma casa tem centenas de anos - isso certamente significa que ela terá alguns problemas, algumas coisas serão estranhas de serem adaptadas, mas também tem um certo encanto e deve ter sido bem construída. Não quer dizer que seja decrépito. É uma ferramenta simples que se mostrou útil por quatro décadas.
Aqui estão alguns pontos sobre esses dois :
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.
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
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, ...
com a opção dependências, assim como outros serviços systemd, pode haver dependências no tempo de ativação.
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, ...
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.
Ative / desative facilmente a coisa toda com:
e mate todos os filhos do trabalho com:
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, ...
eventos de hora do systemd (calendário) são mais precisos que o cron (parece 1s de precisão)
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 :
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.
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.
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.
— F.sb
É um bom esforço, obrigado. No entanto, comparações mais diretas com o cron seriam úteis, incluindo um exemplo. Além disso, parte do que você escreve não é totalmente clara, por exemplo, "do ponto de vista de uso da CPU, o systemd timer acorda a CPU no tempo decorrido, mas o cron faz isso com mais frequência".
Olá, @ F.sb! Sua resposta parece sugerir que você pode agendar trabalhos usando diferentes fusos horários. Isso está correto? Como você faria isso? Seria uma vantagem significativa sobre as implementações padrão do cron, mas não consegui encontrar nenhuma informação sobre ele, exceto a man systemd.timeque parece contradizê-lo: fusos horários não locais, exceto o UTC, não são suportados.
— Tad lispy
As dependências são úteis. Por exemplo, se o backup do host for executado como um timer do systemd, você poderá usar dependências para garantir que a exportação do banco de dados seja concluída imediatamente antes do backup.
— vk5tu
Por favor, seja mais honesto na frente. Você começa dizendo que esses são alguns pontos sobre os dois e depois continua listando as vantagens de sua escolha preferida . Não é ruim que você tenha uma preferência, mas você deve declarar isso com antecedência. Além disso, o fato de ser tudo a favor de um sistema e não olhar para os profissionais que o sistema me faz sentir que essa resposta está distorcida.
@jasper querido, eu uso os dois com base nas minhas necessidades, e é sempre sua escolha escolher um com base nas suas necessidades, acabei de mencionar alguns fatos com base em documentos e manuais.
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:
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.
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 =.
— shdwlynx
Errr ... não sei como me sinto em relação a uma resposta que é quase inteiramente copiar e colar, especialmente porque as licenças não são compatíveis. Mas, no mínimo, você deve corrigir esse bit "consulte a próxima seção". Com esse erro, parece que você não leu o que copiou e colou.
Ao citar material de algum lugar, você deve citar a fonte e indicar claramente o que é citado . Plágio não é legal .