Puncte:1

Este posibil să folosiți ambele opțiuni `După=` și `Înainte=` pentru aceeași unitate (serviciu) împreună în serviciul systemd?

drapel in

The Type=onehot unitate Un serviciu este pornit din oră de A.cronometru si el Vrea=B.serviciu, dar aleargă Înainte=B.serviciu. Unitate B.serviciu este de asemenea Type=onehot. Cerința aici este ca procesele lor să nu se suprapună niciodată în timpul rulării (o singura sansa asigură exact asta), totul grozav până acum. Acum imaginați-vă un scenariu în care ambele A și B împreună rulează mai mult de o oră (timpul între A.cronometru incendii). Există două posibilități aici:

  1. A rulează mai mult de o oră, apoi deși A.cronometru vrea să tragă și probabil că face, indiferent, un alt exemplu de A nu va fi pornită până când primul se termină, deoarece unicitatea instanței de serviciu este unul dintre principiile fundamentale în systemd. Cred că va fi doar la coadă. Din nou, totul grozav până acum, nu avem niciun risc de a suprapune procese în timpul execuției aici.
  2. A rulează suficient de mult, astfel încât B, care rulează ulterior, rulează, de asemenea, suficient de mult pentru a depăși o oră în total și, ca urmare, A.cronometru incendii să pornească noi A in timp ce B încă rulează. Acolo ne întâlnim cu o suprapunere a proceselor pentru că nu există După=B.serviciu în Un serviciu așa cum există deja Înainte=B.serviciu.

Întrebarea mea este, practic, dacă este valabil să le avem chiar și pe amândouă După=B.serviciu și Înainte=B.serviciu în Un serviciu in primul loc? Și, desigur, ar rezolva problema de suprapunere descrisă în a doua posibilitate așa cum mă aștept teoretic? Mai este vreun altul systemd-mod de a rezolva această problemă (de exemplu, nu vreau să mă implic cu umflarea fișierelor de blocare predispuse la erori)?

Michael Hampton avatar
drapel cz
Probabil ar trebui să setați o „Condiție...=” în schimb.
Puncte:2
drapel br

Dacă creați un Înainte= si un După= în dumneavoastră Un serviciu fișier, veți primi o eroare:

A.service: Job B.service/start șters pentru a întrerupe ciclul de comandă începând cu A.service/start

Pentru că Systemd nu vrea să aibă ambele dependențe de aceeași unitate. Nu cred că niciunul dintre Stare...= din man systemd.unitate pe care Michael le-a menționat sunt potrivite pentru sarcina pe care încercați să o îndepliniți, cu excepția cazului în care comenzile dvs. creează și apoi își curăță propriile fișiere. După cum văd eu, aveți două soluții principale posibile:

  1. Creaza un ExecCondition= în dumneavoastră Un serviciu care rulează o comandă pentru a verifica dacă B.serviciu rulează.Acest lucru este puțin dificil de făcut doar cu ps și grep din fișierul unității, așa că probabil ați dori să executați un script extern, dar ați spus deja că doriți să evitați un fișier de blocare dezordonat, așa că probabil că nu este ideal.
  2. Utilizați soluția dezordonată pentru fișierul de blocare pe care ați menționat-o pe care nu ați vrut să o utilizați
  3. Mutați a doua comandă din B.serviciu și într-o ExecStopPost= opțiunea în Un serviciu. Aceasta va face ca a doua comandă să ruleze numai după ce prima comandă s-a oprit. De asemenea, va preveni un nou Un serviciu de la alergare înainte ca primul să se termine complet. Cred că acest lucru vă îndeplinește toate dorințele, de când Un serviciu comanda si B.serviciu comanda nu va fi niciodată rulată în același timp, două Un serviciu comenzile nu vor fi niciodată rulate una lângă alta, iar noile execuții vor fi doar puse în coadă.

Iată fișierul unitar pe care l-am folosit pentru a testa opțiunea 3:

[Unitate]
Descriere = A.service pentru serverfault
[Serviciu]
Tip = oneshot
# A.comandă de serviciu
ExecStart = /usr/bin/sleep 3 
# B.comandă de serviciu
ExecStopPost = /usr/bin/sleep 30

Și apoi testat folosind systemctl start A.service în mod repetat în mai multe ferestre de terminale, monitorizarea progresului cu care procese rulau efectiv la un moment dat ps.

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.