PROCESS_LAUNCH_ in C stops responding when parent is killed

[Luis Silva]

Hi,

I have a program that calls PROCESS_LAUNCH_ with no problems, it launcehs a new process that opens a socket and wiats for a connection. Everything works fine. but.... If I close parent process child process is still running but it wont process no new data.

Is there some sort of nohup when calling PROCESS_LAUNCH_ so that even if the caller dies the new process can still receive data over its socket?

[Bill Honaker]

Post by Luis Silva
Hi,
I have a program that calls PROCESS_LAUNCH_ with no problems, it launcehs a new process that opens a socket and wiats for a connection. Everything works fine. but.... If I close parent process child process is still running but it wont process no new data.
Is there some sort of nohup when calling PROCESS_LAUNCH_ so that even if the caller dies the new process can still receive data over its socket?

Luis, we need a few more details. Please answer a few questions.

Are the launcher and the launched processes in OSS or Guardian?
What language is the launched process written in?
Are you sending the 'Startup' message to the launched process?
Are you allowing the 'hometerm' of the launched process to default to the hometerm if the launcher?
(Suggestion: use $ZHOME as the hometerm).
Does the launched process write to stdout or stderr? Or to the Home terminal?

Bill

[Luis Silva]

Hi,

It is a Guardian process written in C
All output is done via printf(....);

What I have is:
process_launch_params_def proc_params = P_L_DEFAULT_PARAMS_;
startup_msg_type smt;

get_startup_msg(&smt, &smtlen);

proc_para.program_name = pname;
...
proc_param.name_options = ZSYS_VAL_PCREATOPT_NAMEINCALL;

PROCESS_LAUNCH(
&proc_param,
&errordetail,
&proc_results,
sizeof(proc_results).
&outlen);


This launches the new process with no problems, I can use the new process wirth bo problem, send info, get info all of its functionality, but if I kill/close the process that issued the PROCESS_LAUNCH_ a status *,user tells me the "child" process is active but I cant interact with it.

[Bill Honaker]

Post by Luis Silva
Hi,
It is a Guardian process written in C
All output is done via printf(....);
process_launch_params_def proc_params = P_L_DEFAULT_PARAMS_;
startup_msg_type smt;
get_startup_msg(&smt, &smtlen);
proc_para.program_name = pname;
...
proc_param.name_options = ZSYS_VAL_PCREATOPT_NAMEINCALL;
PROCESS_LAUNCH(
&proc_param,
&errordetail,
&proc_results,
sizeof(proc_results).
&outlen);
This launches the new process with no problems, I can use the new process wirth bo problem, send info, get info all of its functionality, but if I kill/close the process that issued the PROCESS_LAUNCH_ a status *,user tells me the "child" process is active but I cant interact with it.

Not too familiar with PROCESS_LAUNCH_, will try to read the manual later. From your example above I don' t know what your startup message looks like.
But part of that message includes the name of the IN and OUT files of the process, which map to stdin and stdout. If those include a 'hometerm' then
your child process may be trying to interact with your interactive TACL session and be getting hung up.

Bill

[Randall]

Post by Luis Silva
Hi,
It is a Guardian process written in C
All output is done via printf(....);
process_launch_params_def proc_params = P_L_DEFAULT_PARAMS_;
startup_msg_type smt;
get_startup_msg(&smt, &smtlen);
proc_para.program_name = pname;
...
proc_param.name_options = ZSYS_VAL_PCREATOPT_NAMEINCALL;
PROCESS_LAUNCH(
&proc_param,
&errordetail,
&proc_results,
sizeof(proc_results).
&outlen);
This launches the new process with no problems, I can use the new process wirth bo problem, send info, get info all of its functionality, but if I kill/close the process that issued the PROCESS_LAUNCH_ a status *,user tells me the "child" process is active but I cant interact with it.

A few things:

SIGHUP is not processed by a GUARDIAN process, only OSS. So the child will not receive a SIGHUP if the parent is killed. If you want to monitor for the death of a GUARDIAN parent from an OSS process, you need to open $RECEIVE in the child and monitor for system messages. You will likely end up with having to either make the child process threaded or use select().

Similarly, the GUARDIAN process will not receive a SIGCHLD when the child dies.

The child may detect the death of any pseudo terminal you use, but only if it attempts an I/O on it. You will probably get a SIGPIPE in that case.

You must ensure that the stdin, stderr, and stdout of the child processes are compatible with OSS.

The behaviour you are describing is not surprising at all.

[Bill Honaker]

Post by Randall

Post by Luis Silva
Hi,
It is a Guardian process written in C
All output is done via printf(....);
process_launch_params_def proc_params = P_L_DEFAULT_PARAMS_;
startup_msg_type smt;
get_startup_msg(&smt, &smtlen);
proc_para.program_name = pname;
...
proc_param.name_options = ZSYS_VAL_PCREATOPT_NAMEINCALL;
PROCESS_LAUNCH(
&proc_param,
&errordetail,
&proc_results,
sizeof(proc_results).
&outlen);
This launches the new process with no problems, I can use the new process wirth bo problem, send info, get info all of its functionality, but if I kill/close the process that issued the PROCESS_LAUNCH_ a status *,user tells me the "child" process is active but I cant interact with it.

SIGHUP is not processed by a GUARDIAN process, only OSS. So the child will not receive a SIGHUP if the parent is killed. If you want to monitor for the death of a GUARDIAN parent from an OSS process, you need to open $RECEIVE in the child and monitor for system messages. You will likely end up with having to either make the child process threaded or use select().
Similarly, the GUARDIAN process will not receive a SIGCHLD when the child dies.
The child may detect the death of any pseudo terminal you use, but only if it attempts an I/O on it. You will probably get a SIGPIPE in that case.
You must ensure that the stdin, stderr, and stdout of the child processes are compatible with OSS.
The behaviour you are describing is not surprising at all.

Randall, note that Luis said these are all Guardian processes, not OSS.

[wbreidbach]

Post by Bill Honaker

Post by Randall

Post by Luis Silva
Hi,
It is a Guardian process written in C
All output is done via printf(....);
process_launch_params_def proc_params = P_L_DEFAULT_PARAMS_;
startup_msg_type smt;
get_startup_msg(&smt, &smtlen);
proc_para.program_name = pname;
...
proc_param.name_options = ZSYS_VAL_PCREATOPT_NAMEINCALL;
PROCESS_LAUNCH(
&proc_param,
&errordetail,
&proc_results,
sizeof(proc_results).
&outlen);
This launches the new process with no problems, I can use the new process wirth bo problem, send info, get info all of its functionality, but if I kill/close the process that issued the PROCESS_LAUNCH_ a status *,user tells me the "child" process is active but I cant interact with it.

SIGHUP is not processed by a GUARDIAN process, only OSS. So the child will not receive a SIGHUP if the parent is killed. If you want to monitor for the death of a GUARDIAN parent from an OSS process, you need to open $RECEIVE in the child and monitor for system messages. You will likely end up with having to either make the child process threaded or use select().
Similarly, the GUARDIAN process will not receive a SIGCHLD when the child dies.
The child may detect the death of any pseudo terminal you use, but only if it attempts an I/O on it. You will probably get a SIGPIPE in that case.
You must ensure that the stdin, stderr, and stdout of the child processes are compatible with OSS.
The behaviour you are describing is not surprising at all.

Randall, note that Luis said these are all Guardian processes, not OSS.

The best way to find out what the process is waiting for is using PSTATE on that process.
If the child process has been created for using inspect and with saveabend set to on, you could also try an #abend on the process and analyze the resulting ZZSA-file.

[Luis Silva]

Hi all,

analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,

I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.

The workaround was:

Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).

This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running

I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.

Thank you all for your help

[Bill Honaker]

Post by Luis Silva
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help

Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).

If nothing is blocking, then send the TCP data, and use PTRACE again.

You may need to use the debugger against PROC-B to solve this in 'a better way'.

Bill

[Tone]

Post by Bill Honaker

Post by Luis Silva
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help

Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).
If nothing is blocking, then send the TCP data, and use PTRACE again.
You may need to use the debugger against PROC-B to solve this in 'a better way'.
Bill

I think Bill meant PSTATE rather than PTRACE.

[Bill Honaker]

Post by Tone

Post by Bill Honaker

Post by Luis Silva
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help

Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).
If nothing is blocking, then send the TCP data, and use PTRACE again.
You may need to use the debugger against PROC-B to solve this in 'a better way'.
Bill

I think Bill meant PSTATE rather than PTRACE.

Tone is correct, PSTATE is the too to use. My apologies.
Bill

[Luis Silva]

Post by Tone

Post by Luis Silva
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help

Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).
If nothing is blocking, then send the TCP data, and use PTRACE again.
You may need to use the debugger against PROC-B to solve this in 'a better way'.
Bill

I think Bill meant PSTATE rather than PTRACE.

Tone is correct, PSTATE is the too to use. My apologies.
Bill

Hi all,

I've got this solved, whay I did was pass the prcoess nake to the child process, so it can make some sort or heartbeat.
If the parent dies the child process finishes it current operation and exits.

[wbreidbach]

Post by Luis Silva

Post by Tone

Post by Luis Silva
Hi all,
analyzing all your posts (thank you very much for all the input!!) I was able to workaround this issue. Not in an elegant way but I was able to make it work,
I had a guardian C process PROC-A that launches another c process PROC-B which opens a tcp port and waits for I/O. If I kill, stop $PROC-A (the father) $PROC-B is still shown is status *,user but if I try to send data to it via TCP (as it is is function) it doesn't do anything. As if in a vegetative state.
Instead of calling PROC-B from PROC-A (with a process launch) I call an intermediate process PROC-BYPASS via a process launch and this PROC-BYPASS calls a system(PROC-B).
This way if PROC-A dies or any of PROC-BYPASS dies the required PROC-B is still up and running
I know it is the least elegant way. I'll keep reading the manuals to see if I find a better way.
Thank you all for your help

Wolfgang made a good suggestion. Before trying to send TCP to PROC-B after PROC-A is gone,
use PTRACE against PROC-B to find out what if anything is blocking the process. Note that the '%WT'
value in the TACL STATUS tells you a little, but PTRACE is much more informative (sometimes).
If nothing is blocking, then send the TCP data, and use PTRACE again.
You may need to use the debugger against PROC-B to solve this in 'a better way'.
Bill

I think Bill meant PSTATE rather than PTRACE.

Tone is correct, PSTATE is the too to use. My apologies.
Bill

Hi all,
I've got this solved, whay I did was pass the prcoess nake to the child process, so it can make some sort or heartbeat.
If the parent dies the child process finishes it current operation and exits.

If the parent process has an OPEN on the child, the child can just check for the close-message which will be created when the parent dies. In addition you get get the info about the parent by using PROCESS_GETINFO_.