Iniciar / parar um systemd.service em horários específicos


14

Quero iniciar e parar um systemd.service em horários específicos. Presumivelmente, usarei uma unidade .timer para iniciar o trabalho, mas existe uma maneira integrada de interromper o trabalho após uma duração específica, ou em um horário específico , ou preciso criar uma segunda unidade .timer que execute o stop?

obrigado

Respostas:


6

Para interromper um serviço A com um timer, você pode criar um serviço do tipo B com o oneshotqual ele entrará em conflito e, em seguida, usar um timer para iniciar o serviço B.

Se uma unidade tiver uma configuração Conflitos = em outra unidade, iniciar a primeira interromperá a segunda e vice-versa. ( fonte )

Um serviço:

[Unit]
Conflicts=B.service
...

B.serviço:

[Unit]
Description=B service description

[Service]
Type=oneshot
ExecStart=/bin/echo ''

B.timer:

[Timer]
AccuracySec=1
OnActiveSec=10

[Install]
WantedBy=timers.target

O seguinte interromperá o serviço A após 10 segundos.

systemctl start A.service
systemctl start B.timer

2

De fato, existe outra maneira de interromper um serviço após determinado tempo de execução configurado no .servicearquivo.

RuntimeMaxSec=...

Você pode não gostar do fato de o serviço ser considerado com falha, mas esse é um resultado mais ou menos lógico da morte de um serviço de longa duração.

Para obter uma resposta melhor, você pode explicar sua lógica de usar um recurso tão incomum. Geralmente, os serviços são executados para sempre ou até que sejam explicitamente interrompidos, não apenas por um período fixo de tempo.


1
Sim, nós discutimos isso e suas limitações na lista de discussão: lists.freedesktop.org/archives/systemd-devel/2016-April/...
Jamie Kitson

1
Não é incomum. Que tal executar um serviço que exige recursos, talvez o SETI, apenas durante a noite, quando o servidor obtém menos tráfego. Além disso, onde trabalho, temos um daemon de alerta projetado para ativar a equipe de suporte por meio de seus telefones quando há uma exceção nos servidores. Realmente não queremos que essa coisa chata funcione quando estamos realmente acordados, porque esses servidores têm problemas para a esquerda e para a direita durante o uso de pico.
James M. Lay

0

Você pode usar algumas tarefas cron:

 # ┌───────────── min (0 - 59) 
 # │ ┌────────────── hora (0 - 23)
 # │ │ ┌─────────────── dia do mês (1-31)
 # │ │ │ ────────────────── mês (1-12)
 # │ │ │ │───────────────── dia da semana (0 - 6)
 # │ │ │ │ │
 # │ │ │ │ │
   * * * * * systemctl start $ SERVICE.service
   * * * * * systemctl para $ SERVICE.service

Mais informações sobre cron: https://en.wikipedia.org/wiki/Cron , https://wiki.archlinux.org/index.php/Cron


8
Como um trabalho cron é uma melhoria em relação às .timerunidades systemd que o OP já conhece?
Pavel Šimerda

Eu poderia, sim, mas minha pergunta é realmente como fazer isso corretamente com o systemd? Suponho que deve haver alguma maneira padrão de conseguir que um emprego pare em um horário específico ou após uma certa duração.
Jamie Kitson

@JamieKitson Para ser honesto eu não acho que há realmente precisa para ser um tal recurso além cron e temporizadores Systemd. A maioria das instalações do systemd nunca usará esses recursos e não há nada errado em executar systemctlusando cron, temporizadores do systemd e o que você quiser. Na minha opinião, esta resposta é tão válida quanto qualquer outra resposta.
Pavel Šimerda

como você permite, por exemplo, ao www-data executar o systemctl start & stop?
Alvaropgl 5/06

@alvaropgl Seu comentário não tem nada a ver com os usuários (www-data) e com o acesso limitado que eles podem ter para executar / não executar processos (systemctl), que é o tópico. Por favor comece um novo tópico. Dica: você provavelmente deseja criar uma API para fazer as coisas que deseja, em vez da sua abordagem atual de habilitar mais responsabilidade + escopo no usuário www-data.
18719 Scott Prive
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.