Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
7 e)
Versenden von Signalen (Version 5.x)
Der job_sh-Prozess soll nun zusätzlich den Sohnprozessen ein SIGQUIT schicken, wenn er
selbst ein SIGINT erhalten hat (kill(2)).
wenn man CTRL+C im terminal drückt, werden doch allen vom terminal aus laufenden prozessen SIGINT geschickt, oder? d.h. wenn dem obigen wörlich folge schießt ein CTRL+C während ein z.b. ein fg-prozess und mehrere hg-prozesse laufen alle prozesse ab, weil ja der job_sh prozess auch ein SIGINT bekommt… ist das so beabsichtigt?
du sollst das SIGINT im vater prozess abfangen und es nur an die söhne weiterleiten damit deine shell nich über ctrl+c abschiessbar is
moment, also sagen wir mal im hintergrund läuft grad irgendein programm, das gerade was berechnet. im vordergrund läuft ein mp3 player… und der hängt (oder auch nicht, is im endeffekt wurscht). ich drück CTRL+C. erwarten würde ich, dass der prozess, der - für mich - gerade läuft (anders ausgedrückt: der vordergrundprozess) abgeschossen wird, mein programm, dass im hintergrund läuft, aber fröhlich weiterläuft.
wir sollen aber implementieren: “Der job_sh-Prozess soll nun zusätzlich den Sohnprozessen ein SIGQUIT schicken”, was ich so verstehe (auch nach deiner antwort) allen söhnen. d.h. mein hg-prozess wird auch mit SIGQUIT abgeschossen… sollen wir das wirklich so machen? oder steh ich immernoch auf dem schlauch :red:
ja
[ ] ja, wir sollen das so implementieren, wenn man CTRL+C drückt sollen alle kinder der job_sh abgeschossen werden und einfach wieder der prompt ausgegeben werden. d.h. auch wenn garkein fg-prozess läuft wird der hintergrund mal “abgeräumt” :-/ dazu mal ein querverweis auf den thread “viele viele fragen”…
[ ] ja, ich steh immernoch auf dem schlauch, du willst mir aber nicht sagen, wie ich runter komme 
p.s: “wenn man CTRL+C im terminal drückt, werden doch allen vom terminal aus laufenden prozessen SIGINT geschickt, oder?” kann das jemand bestätigen bzw. verneinen?
:listen:
ersteres. so wurds mir heut in der übung erklärt. Dein Vordergrund prozess is ja nicht der Vater der anderen prozesse. die werden dann nich gekillt. Nur wenn der shell prozess nen ctrl+c kriegt werden sie söhne gekillt. Darfst den sigint handler halt nur für den shell prozess installieren
Also,
nur um nochmal kurz von “offizieller” Seite zu bestaetigen: So soll es sein. SIGINT an Shell resultiert in SIGQUIT an FG-Prozess und alle HG-Prozesse. Punkt.
wozu muß das sig_quit an den vg prozeß geschickt werden, der bekommt doch schon ein sig_int, oder?
was hat das eine mit dem andern zu tun?! Womöglich ignoriert er das SIGINT oder behandelt es anderweitig…
:finger: also denke ich ,wir brauchen bei aufgabe e) eine jobliste, die aktuelle kinderprozess pid speichern, da kann job_sh bei empfangen von SIGINT mit kill(pid, SIGQUIT) alle kinderprocess beenden.
das problem ist , wie kann man ein kinderprozess von der liste löschen, wenn das prozess schon beendet wurde. :motz:
waitpid(pid) returned sofort wenn der kindprozess nen zombie prozess is.
Gestorbene Kinder werden nicht sofort beerdigt 
man 2 waitpid
So wirklich einen Sinn macht das nicht. Die Childprozesse bekommen halt ein anderes Signal - an dem >90% aller Programme auch sterben werden. Ein Unterschied waere, dass ein coredump erzeugt werden wuerde, wenn das limit nicht auf 0 waere.
Eine sinnvolle Anwendung wuerde leider wieder den zeitlichen Rahmen sprengen, das ist quasi mehr eine Uebung um den Signalmechanismus mal durch zu machen.
ja, 7e ist wirklich nicht besonders sinnvoll. Sorry.
Ich wollte damit wohl einfach haben, dass man auch mal explizit ein
Signal von einem Prozess an einen anderen geschickt hat.
Vor allem ist sie ohne die Joblist gar nicht vernuenftig realisierbar.
Ich glaub, das ist ein Relikt aus einer historisch gewachsenen Aufgabe -
ich hab’ s mir fuer’s naechste Jahr notiert.
Es ist jetzt aber auf jeden Fall ok, wenn man die 7e nach der 7f
macht (und dann einfach ueber die Joblist rennt und die Kinder
niedermacht - Hmmm, irgendwie ist die Teilaufgabe unsozial…)
:#: wieso liefert waitpid immer -1 zurück, wenn ein vordergrundprozess beendet wurde.
mit welchem Fehler (errno)???
wenn’s EINTR ist, dann wurde der Vater durch das SIGCHLD des
gestorbenen Kindes in den sigchld-handler geschickt und dadurch
wurde das wait (obwohl es “so gut wie fertig ware”) noch unterbrochen
und kommt mit “interrupted system call” zurueck.
ECHILD
mein child handler
void sigchild_handler(int signr)
{
int status;
pid_t pid;
while((pid = waitpid(-1, &status, WNOHANG)) > 0) {
if(fg_pid == pid) {
…
} else {
char commandLine[1024];
if(jl_remove_pid(joblist, pid, commandLine, 1024) < 0) {
perror(“Fehler bei jl_remove_pid in sigchild_handler\n”);
return;
}
}
}
}
my excute_fb
fg_pid ist eine globale variabel
void execute_fg(char *commandLine, int argc, char **argv) {
int status;
switch(fg_pid=fork()) {
case -1 : perror(“fork”);return;
case 0 :
execvp(argv[0], argv);
perror(argv[0]);
exit(EXIT_FAILURE);
}
while (waitpid(fg_pid, &status, 0)==-1) {
if (errno==EINTR) continue;
perror("wait");
return;
}
if (WIFSIGNALED(status)) {
printf("Signal [%s] = %d\n",commandLine,WTERMSIG(status));
#ifdef WCOREDUMP
if (WCOREDUMP(status)) printf(" (core dumped)\n");
#endif
} else {
printf(“Exitstatus [%s] = %d\n”, commandLine,WEXITSTATUS(status));
}
if((jl_insert(joblist, (int)fg_pid, commandLine)) == -1) {
perror("Fehler bei jl_insert\n");
return;
}
}
ist der siigchild_handler mit SA_RESTART-flag installiert?