înregistrare Logare
Puncte:3
Paul avatar Server

De ce timer-ul meu systemd se declanșează o singură dată când unitatea este o țintă?

drapel jp
Paul

Am câteva servicii (generatoare statice de site) pe care vreau să le declanșez în mod regulat de la același timer systemd. am găsit această întrebare/răspuns, care acoperă exact ceea ce vreau să fac și descrie o configurație prin care a .ţintă dosar că Vrea= servicii multiple este declanșată de un temporizator corespunzător. Sună grozav, dar constat că atunci când am configurat acest lucru, se declanșează întotdeauna o singura data, apoi se dezactivează!

Am pregătit un exemplu de lucru minim (acest lucru nu declanșează mai multe servicii, dar demonstrează aceeași problemă):

test-timer.timer:

[Unitate]
Descriere=Un cronometru de testare

[Temporizator]
OnCalendar=*-*-* *:*:30
Unit=test-timer.target

[Instalare]
WantedBy=timers.target

test-timer.ţintă:

[Unitate]
Descriere=Unitatea țintă
Wants=test-timer.service
După=test-timer.service

[Instalare]
WantedBy=timers.target

test-timer.service:

[Unitate]
Descriere=Executare test

[Serviciu]
ExecStart=/usr/bin/bash -c "date --rfc-3339='secunde' >> /tmp/test-timer-output"

[Instalare]
Also=test-timer.target

Activați cronometrul:

$ sudo cp test-timer.* /etc/systemd/system/
$ sudo systemctl enable --now test-timer.timer
S-a creat legătura simbolică /etc/systemd/system/timers.target.wants/test-timer.timer â /etc/systemd/system/test-timer.timer.

Apoi, când mă uit la ieșirea lui systemctl list-timers --all, înainte de prima rulare pe care o primesc (ignorând alte cronometre):

URMĂTOAREA STÂNGA ULTIMA UNITATE A TRUCĂ SE ACTIVĂ
Vineri 2021-10-08 10:38:30 EDT 21s rămas n/a n/a test-timer.timer test-timer.target

După prima alergare, URMĂTORUL și STÂNGA au fost înlocuite cu N / A:

URMĂTOAREA STÂNGA ULTIMA UNITATE A TRUCĂ SE ACTIVĂ
n/a n/a Vin 2021-10-08 10:38:32 EDT acum 1min 5s test-timer.timer test-timer.target

Am incercat si eu sa adaug Persistent=adevarat la test-timer.ţintă și activarea în mod explicit test-timer.ţintă, dar niciuna dintre acestea nu funcționează. Oricând o fac systemctl restart test-timer.timer, repornește, dar declanșează doar o rulare, apoi nu mai are niciodată o altă încercare.

Dacă elimin stratul de indirectă prin schimbarea Unitate= linie de test-timer.timer la Unit=test-timer.service, serviciul se declanșează cu bucurie în fiecare minut, așa cum era de așteptat.

Pierd vreun pas de configurare sau instalare?

580
0 + 0
Puncte:3
Paul avatar Server
drapel jp
Paul

După ce am primit ajutor pe Twitter, am reușit să rezolv această problemă. Problema este că un systemd temporizator va activa numai serviciile care sunt inactive și comportamentul implicit pentru a ţintă este să se activeze și să rămână activ, cu excepția cazului în care ceva îl face să se defecteze (nu este legat de durata de viață a unităților pe care le Vrea=). Pentru a forța unitatea țintă să devină inactivă dacă orice a serviciilor pe care le activează devine inactiv, utilizare BindsTo= in locul Vrea= în exemplul meu de mai sus. Deci, pentru acest exemplu minim:

test-timer.ţintă:

[Unitate]
Descriere=Unitatea țintă
BindsTo=test-timer.service
După=test-timer.service

[Instalare]
WantedBy=timers.target

test-timer.service:

[Unitate]
Descriere=Executare test

[Serviciu]
ExecStart=/usr/bin/bash -c "date --rfc-3339='secunde' >> /tmp/test-timer-output"

[Instalare]
Also=test-timer.target

Apoi puteți vedea asta de îndată ce test-timer.service s-a terminat de alergat, test-timer.ţintă va deveni de asemenea inactiv (și astfel cronometrul îl va putea activa din nou):

$ sudo systemctl list-units --all test-timer.target test-timer.service
  SUBDESCRIERE ACTIVĂ DE ÎNCĂRCARE UNITĂ
  test-timer.service încărcat inactiv mort Run test   
  test-timer.target încărcat inactiv mort Unitate țintă

În timp ce înainte de schimbare, ținta rămânea activă după ce serviciul a murit:

$ sudo systemctl list-units --all test-timer.target test-timer.service
  SUBDESCRIERE ACTIVĂ DE ÎNCĂRCARE UNITĂ
  test-timer.service încărcat inactiv mort Run test   
  test-timer.target loaded activ activ Unitate țintă
0 + 0
drapel za
Kevin P. Fleming
Dagnabbit, ai găsit soluția înainte să o pot posta :-)
0
Răspunde
karlsebal avatar
drapel in
karlsebal
Mai ales atunci când aveți mai multe servicii declanșate de o țintă și toate sunt unice, puteți utiliza `StopWhenUnneeded=True`. Acest lucru va face ca ținta să devină inactivă după ce munca a fost terminată.
3
Răspunde
drapel ma
Chih-Hsuan Yen
Se pare că `StopWhenUnneeded=` funcționează mai bine decât `BindsTo=`. Cu acesta din urmă, am primit o eroare `xxx.target: Bound to unit yyy.service, but unit isn't active` ori de câte ori ținta este activată.
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.