Evita que o timer do systemd seja executado na inicialização

Question

Eu tenho migrado meus crontabs para as unidades temporizadas do systemd. Todos eles são parecidos com isso:

arquivo

.timer:

[Unit]
Description=timer that uses myjob.service

[Timer]
OnCalendar=*-*-* *:00:00
Unit=myjob.service

[Install]
WantedBy=timers.target

arquivo .service:

[Unit]
Description=Script that runs myjob.sh

[Service]
ExecStart=/home/user/myjob.sh

Meus temporizadores funcionam, mas também são executados na reinicialização do sistema. Gostaria que meus eventos do OnCalendar fossem executados somente nos horários especificados, não em qualquer horário aleatório que eu reinicializasse o PC. Alguma idéia?

ATUALIZAÇÃO: Eu resolvi esse problema convertendo meus timers 'user' em timers root / system.

1. Eu desabilitei todos os meus arquivos .service e .timer e os movi para fora do meu diretório home em / etc / systemd / system.

2. Eu adicionei a seção 'Usuário =' a cada arquivo de serviço, para que meus scripts fossem executados pelo usuário regular e não como raiz.

Agora meus temporizadores não estão sendo acionados na inicialização do sistema e eu também estava tendo problemas com o acionamento esporádico quando eu fiz login via ssh. Isso também foi resolvido agora que eles estão sob o controle da conta raiz, mas executar meus scripts ainda são executados como o PID do usuário comum, o que preserva os atributos de propriedade dos meus arquivos. Problema resolvido.

    

Answer 1

Eu resolvi esse problema convertendo meus timers de 'usuário' em timers root / system.

1. Eu desabilitei todos os meus arquivos .service e .timer e os movi para fora do meu diretório home em / etc / systemd / system.

2. Eu adicionei a seção 'Usuário =' a cada arquivo de serviço, para que meus scripts fossem executados pelo usuário regular e não como raiz.

Agora meus temporizadores não estão sendo acionados na inicialização do sistema e eu também estava tendo problemas com o acionamento esporádico quando eu fiz login via ssh. Isso também foi resolvido agora que eles estão sob o controle da conta raiz, mas executar meus scripts ainda são executados como o PID do usuário comum, o que preserva os atributos de propriedade dos meus arquivos. Problema resolvido.

_{O OP postou isso como uma edição da pergunta, então eu a reproduzi aqui.}

    

Answer 2

De acordo com documentação , você deve alterar sua configuração para Persistent=false ou remover Persistent , porque é falso por padrão.

    

Answer 3

Eu também estava tendo o mesmo problema e não conseguia entender por que as unidades sempre funcionavam na inicialização, independentemente da configuração Persistent no arquivo .timer, e demorei um pouco, mas finalmente encontrei a causa (apontada no direção certa pelo comentário de @ alexander-tolkachev).

O problema é que sempre incluímos algo como WantedBy=basic.target na seção [Install] do arquivo .service (porque é parte do padrão systemd copy copy pasta). Acontece que isso realmente faz com que a unidade seja iniciada sempre que basic.target é (também conhecido como inicialização do sistema).

link link

Eu suspeito que o OP resolveu inadvertidamente o problema desabilitando o antigo .service (que você deve fazer para remover o link simbólico criado por WantedBy ) e omitindo a seção [Install] quando eles o escreveram novamente ou nunca executando systemctl enable .

TLDR; Você não deseja uma seção [Install] em um arquivo .service que seja acionado por um arquivo .timer.

    

Answer 4

Ao investigar esse problema no meu próprio servidor, descobri o seguinte:

$ systemctl status man-db.timer
Apr 09 08:10:00 anemone systemd[1]: man-db.timer: Not using persistent file timestamp Mon 2018-04-16 19:40:02 EDT as it is in the future.
Apr 09 08:10:00 anemone systemd[1]: Started Daily man-db cache update.

Acontece que a bateria do RTC on-board estava morta, então o sistema estava inicializando com uma data no passado (provavelmente tirada do sistema de arquivos). Confirmado pela execução

journalctl --boot

E vendo que os logs da inicialização atual têm registros de data e hora incorretos. Adicionando isso caso o problema de qualquer outra pessoa coincida com o meu.