Tema va fi rezolvată exclusiv de asistenți.

• 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

• 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.

• 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.”

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ă

• 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

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.

• Arhiva inițială cu soluții
• Arhiva actualizată cu soluții

• 6 teste publice
• Pagina de descriere a testelor

• 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 legate de Tema Asist

~~DISCUSSION~~