I thought I had a solution to my problems but NOT. I want
to allow the user to kill a child process with control-c
but have the parent process survive. I also want the
child and parent to die if the parent process is killed.

I thought that setpgid() offered an answer but that routine
seems to be broken now.

Any suggestions other than dis-allowing control-c in the child?

TIA

root wrote:
SIGKILL can't be caught or ignored; do you mean SIGINT (^C)?

> I thought I had a solution to my problems but NOT. I want
> to allow the user to kill a child process with control-c
> but have the parent process survive. I also want the
> child and parent to die if the parent process is killed.
>
> I thought that setpgid() offered an answer but that routine
> seems to be broken now.
>
> Any suggestions other than dis-allowing control-c in the child?

root wrote:

> I thought I had a solution to my problems but NOT. I want to allow the
> user to kill a child process with control-c but have the parent
> process survive.

Catch the SIGINT in the parent (which is what I assume still controls
the terminal), and forward it to the child process when it occurs.

> I also want the child and parent to die if the parent process is
> killed.

Well, the parent process obviously dies if killed, but to kill the
children as well, it should work with making it a process group and
monitor for the appropriate signals that indicate orphaning (though my
memory is a bit rusty, so I could be wrong).

> I thought that setpgid() offered an answer but that routine seems to
> be broken now.

Could you explain in a little more detail (perhaps with code) what you
are doing? Nothing personal, but in my experience it is more common
that people use the tools wrong, rather than the tools being broken
themselves ... ;-)

> Any suggestions other than dis-allowing control-c in the child?

Is the child really the one receiving the SIGINT?

--
PeKaJe

I can just imagine a cluster of Windows machines. They'd have to have a team
of MCSE's equipped with roller skates, just to keep pressing reset buttons ...

Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
> root wrote:
> SIGKILL can't be caught or ignored; do you mean SIGINT (^C)?
>

I am sorry I didn't explain well enough. I want a SIGKILL of the
parent to kill both parent and child, but a SIGINT for the
child should not kill the parent as well.

With a normal fork() each of these is exactly the way I don't
want: SIGKILL of the parent leaves the orphan child, and
control-c in the child kills it and the parent.


>> I thought I had a solution to my problems but NOT. I want
>> to allow the user to kill a child process with control-c
>> but have the parent process survive. I also want the
>> child and parent to die if the parent process is killed.
>>
>> I thought that setpgid() offered an answer but that routine
>> seems to be broken now.
>>
>> Any suggestions other than dis-allowing control-c in the child?
>

Thanks for responding.

Peter Kai Jensen <usenet@pekajemaps.homeip.net> wrote:
> root wrote:
>
>> I thought I had a solution to my problems but NOT. I want to allow the
>> user to kill a child process with control-c but have the parent
>> process survive.
>
> Catch the SIGINT in the parent (which is what I assume still controls
> the terminal), and forward it to the child process when it occurs.
>

No, in my application the child is in the foreground and controls
the terminal.

>> I also want the child and parent to die if the parent process is
>> killed.
>
> Well, the parent process obviously dies if killed, but to kill the
> children as well, it should work with making it a process group and
> monitor for the appropriate signals that indicate orphaning (though my
> memory is a bit rusty, so I could be wrong).
>
>> I thought that setpgid() offered an answer but that routine seems to
>> be broken now.
>
> Could you explain in a little more detail (perhaps with code) what you
> are doing? Nothing personal, but in my experience it is more common
> that people use the tools wrong, rather than the tools being broken
> themselves ... ;-)

No offense taken, if my code is wrong it is wrong, my fault.

lpexec(string)
char *string;
{
int status;

if(fork()==0) {

setpgrp(); <=======This is broken

execlp("/bin/sh","sh","-c",string,(char *)0);
_exit(-99);
}
wait(&status);
}

Sometime after writing this code the setpgrp() routine broke. It just
hangs now and I don't get to the child. As far as I can remember
when setpgrp() did work a SIGKILL of the parent did kill the
child, but it has been so long that I might be wrong.



>
>> Any suggestions other than dis-allowing control-c in the child?
>
> Is the child really the one receiving the SIGINT?
>

Yes, the child is in control of the terminal while it is alive.

root wrote:

....
> No offense taken, if my code is wrong it is wrong, my fault.
>
> lpexec(string)
> char *string;
> {
> int status;
>
> if(fork()==0) {
>
> setpgrp(); <=======This is broken

How are you sure this is broken?
Do you check pre- & post- the value of the process's group?
Does it hang on call?

> execlp("/bin/sh","sh","-c",string,(char *)0);
> _exit(-99);
> }
> wait(&status);
> }
>
> Sometime after writing this code the setpgrp() routine broke. It just
> hangs now and I don't get to the child.

How do you know the process has hung?
Is there no child or does that appear to have hung as well?

> As far as I can remember
> when setpgrp() did work a SIGKILL of the parent did kill the

> child, but it has been so long that I might be wrong

root wrote:

> Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
>
>>root wrote:
>>SIGKILL can't be caught or ignored; do you mean SIGINT (^C)?
>
> I am sorry I didn't explain well enough. I want a SIGKILL of the
> parent to kill both parent and child, but a SIGINT for the
> child should not kill the parent as well.

>

> With a normal fork() each of these is exactly the way I don't
> want: SIGKILL of the parent leaves the orphan child, and
> control-c in the child kills it and the parent.

After the fork() change the handler of SIGINT in the parent to, say,
SIG_IGN? Then ^Cing should kill the child and not the parent.

Do you have to SIGKILL the parent, or could you use another signal, eg
SIGUSR1, which the parent could trap and then use to kill the child (eg
SIGINT) before exiting [cleanly] itself?

Are you looking for a method whereby if the parent dies for some reason, the
child also dies, but the child itself can be killed by a ^C, in which case
the parent just notices that its child has died and continues with something
else?

Alternatively, have a look at the source of, say, bash to see how it does
signal handling.

Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
>
> How do you know the process has hung?
> Is there no child or does that appear to have hung as well?
>

The child process doesn't start.

>> As far as I can remember
>> when setpgrp() did work a SIGKILL of the parent did kill the
>
>> child, but it has been so long that I might be wrong
>

Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
> root wrote:
>
> After the fork() change the handler of SIGINT in the parent to, say,
> SIG_IGN? Then ^Cing should kill the child and not the parent.
>
> Do you have to SIGKILL the parent, or could you use another signal, eg
> SIGUSR1, which the parent could trap and then use to kill the child (eg
> SIGINT) before exiting [cleanly] itself?
>



> Are you looking for a method whereby if the parent dies for some reason, the
> child also dies, but the child itself can be killed by a ^C, in which case
> the parent just notices that its child has died and continues with something
> else?
>

That is exactly what I want. Of the two, however, the ^C killing of the
child without killing the parent is more important. I have temporarily
disabled SIGINT to ensure that the child can't kill the parent.

root <NoEMail@home.org> wrote:
> Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
>>
>> How do you know the process has hung?
>> Is there no child or does that appear to have hung as well?
>>
>
> The child process doesn't start.

After writing this I went back an tried a simple child process
that prints a line and does getchar(); That process starts, whereas
a more complicated process that does direct writing to the screen
does not start. In any case, using setpgrp() in the child process
does not prevent SIGINT from killing the parent.


>
>>> As far as I can remember
>>> when setpgrp() did work a SIGKILL of the parent did kill the
>>
>>> child, but it has been so long that I might be wrong
>>

Even if setpgrp() did, once, solve my problem, it doesn't now.

root wrote:

> root <NoEMail@home.org> wrote:
>
>>Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
>>
>>>How do you know the process has hung?
>>>Is there no child or does that appear to have hung as well?
>>>
>>The child process doesn't start.
>
> After writing this I went back an tried a simple child process
> that prints a line and does getchar(); That process starts, whereas
> a more complicated process that does direct writing to the screen
> does not start.

Suspicion would then lie with the complicated program not starting...have
you checked that the execlp() has worked and not failed? (ie put some sort
of debug stastement after it.)

> In any case, using setpgrp() in the child process
> does not prevent SIGINT from killing the parent.

From my experiments, it wouldn't - it protects the /child/ process. By
changing the child's process group to be different to that of the
controlling terminal, any SIGINT generated by ^C at the terminal sent to its
process group would /not include/ the child, *but* would /include/ the /parent/.
>

>>>> As far as I can remember
>>>>when setpgrp() did work a SIGKILL of the parent did kill the
>>>>child, but it has been so long that I might be wrong

I would suspect that "when setpgrp() did work", SIGINT would kill the
parent, but the child would still be running.

Robert Newson <ReapNewsB@bullet3.fsnet.oc.ku> wrote:
>
> I would suspect that "when setpgrp() did work", SIGINT would kill the
> parent, but the child would still be running.
>

for a child program that is:

printf("Child\n");
getchar();

setpgrp(); does not hang, and I see the Child statement. A Control-C
kills both parent and child. I have pretty much run out of ideas,
so, for now, I have disabled SIGINT.