Tema Asistenți - Guardian process

Tema va fi rezolvată exclusiv de asistenți.

Scopul temei

  • Să ofere răspunsuri la următoarele întrebări
  • Care este nivelul așteptat al soluțiilor temelor?
  • Cum arată o temă de 100p la SO?
    • Exemple de cod bine scris - programming techniques & coding style
    • Makefile
    • README

Enunț

  • Să se implementeze un Guardian Process simplu, care oferă suport pentru pornirea, repornirea și oprirea unui proces. Aplicația se va asigura că o singură instanță a sa rulează la un moment dat. Output-ul generat de programul copil va fi salvat în două fișiere, pentru ieșirea standard și ieșirea standard de eroare.
  • Un proces guardian are rolul de repornire a unui proces/serviciu în momentul în care acesta își încheie brusc execuția. Când procesul copil moare, guardianul va trebui automat să-l repornească cu argumentele lansării anterioare.

Precizări generale

  • Programul se rulează astfel
    • $ ./guardian nume_program param1 param2 …
    • nume_program se va căuta în directoarele din $PATH și în directorul curent
  • Guardianul va salva ieșirile procesului protejat, nume_program, în ./nume_program.stdout și ./nume_program.stderr
  • ./guardian ls
    • ls.stdout
    • ls.stderr
  • O singură instanță de guardian poate rula, la un moment dat, pe un sistem
    • ./guardian sleep 100
    • ./guardian pwd – semnalează eroare
  • Interacțiunea utilizatorului cu aplicația se va face cu semnale, pe GNU/Linux, și evenimente, pe Windows
    • Semnalele au frecvenţă suficient de mică încăt să poată fi tratate pe măsură ce apar
  • Operația de repornire constă în oprirea și pornirea procesului copil, cu argumentele anterioare
    • Oprirea constă în terminarea, posibil bruscă, a execuției programului copil
    • Pentru oprire se poate trimite orice semnal de genul: SIGSTOP, SIGTERM sau SIGKILL
    • man 7 signal: “The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.”

Precizări GNU/Linux

Rulează sub forma de daemon

Guardian Process-ul va intercepta următoarele semnale

  • SIGCONT - repornește procesul copil
  • SIGINT - oprește procesul copil și se închide
  • Restul semnalelor se pot ignora
  • Dacă ignorați SIGCHLD atunci s-ar putea să nu știți când copilul reusește să execute comanda și când nu

Pentru a simplifica implementarea, puteți presupune că procesul copil nu va ieși decât cu codul 0

  • Este “valid”: exit(EXIT_FAILURE);
  • În realitate nu este corect, soluția lui LG este completă
    • Dacă copilul nu reusește execuția programului dat ca parametru, atunci trimite un octet pe PIPE-ul cu părintele
    • Dacă parintele reusește să citească octetul, atunci programul copil nu există

Precizări Windows

  • Poate rula sub formă de serviciu Windows (nu este obligatoriu)
  • Windows Service este un concept ce ține de Windows programming, nu de OS programming

Guardian Process-ul va intercepta următoarele evenimente

  • CTRL_BREAK_EVENT - repornește procesul copil
  • CTRL_C_EVENT - oprește procesul copil și se închide
  • Restul evenimentelor se pot ignora

Întrebări

  1. Ce afișăm dacă un guardian deja rulează ?
    fprintf(stderr, "Guardian is already running\n");
  2. Ce afișăm dacă guardianul este rulat fără parametri în linia de comandă?
    fprintf(stderr, "Usage: nume_program arg1 arg2 ...\n");
  3. Ce afisam daca guardianul nu gaseste programul copil?
    fprintf(stderr, "The child program does not exist!\n");
  4. Se pot aplica redirectări pe programul copil?
    • Nu. Redirectările (>, 2> , &>) sunt ilegale
  5. Ce se întâmplă cu intrarea standard a procesului copil?
    • Se redirectează din /dev/null
  6. In ce mod deschidem fisierele pentru redirectarea procesului copil?
    • In modul append
  7. Ce se intampla daca numele programului exista ca fisier pe disc, dar nu este executabil?
    • Daca apelul functiei din familia exec va esua, atunci raportati ca nu exista fisierul respectiv
  8. Când guardianul oprește procesul copil, trebuie să oprească și copii acestuia?
    • Nu. Procesul copil nu va face spawn la alți copii
  9. Dacă utilizatorul rulează /bin/ls, unde se fac fişierele de log? În calea din care a fost pornit guardianul sau în /bin?
    • În calea din care a fost pornit guardianul
  10. Care este ordinea în care căutăm? Întâi în $PATH, sau întâi în directorul curent?
    • Ordinea în care guardianul se “uită” este stabilită de variabila $PATH; directorul curent se adaugă la sfârșitul șirului de directoare din $PATH
  11. Programul care este instrumetat va moşteni variabilele de mediu?
    • Da, va moșteni variabilele de mediu
  12. La restart, fişierele de logare vor fi trunchiate?
    • Nu. Se vor deschide cu append; checkerul va șterge fișierele stdout și stderr dintr-o sesiune
  13. Este recomandat să nu tratăm SIGSEGV și alte semnale?
    • NU, într-o aplicație reală aceste semnale trebuiesc tratate pentru că reprezintă o modalitate simplă de reparare a erorilor din codul vostru. Scopul temei nu este să ajungă o aplicație reală, ci una ușor de înțeles și care poate fi luată drept model de rezolvare pentru teme.

Rezolvare

Testare

  • 6 teste publice
  • Pagina de descriere a testelor

Status

  • Teste
    • GNU/Linux 6/6
    • Windows 6/6
  • Implementări terminate
    • GNU/Linux
    • AF - Andrei Faur
    • BD - Bogdan Druțu
    • CM - Cătălin Moraru
    • DB - Daniel Baluță
    • LC - Lucian Cojocar
    • LD - Laurențiu Dascălu
    • LG - Lucian Adrian Grijincu
    • OB - Oana Baron
    • VD - Vlad Dogaru
    • IS - Irina Stănescu
    • Windows
    • LD - Laurențiu Dascălu

Comentarii

so/teme/tema-asist.txt · Last modified: 2016/03/13 12:21 by razvan.deaconescu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0