Launching a program using C++ code

[Schadenfroh]

Hey,

I am trying to launch an external program to capture its (debug) output to a textfile.

What I have tried is assigning it to a thread and then trying to kill the thread, but it does not kill the application. For example (having omitted the program that I am intending to run and just using gedit with no debug output capturing):

Prototype / imports:

#include <pthread.h>
#include <sys/signal.h>
void *executeApp(void *);

code to create child thread and then kill it after a delay:

pthread_t cTid;
pthread_create(&cTid, NULL, executeApp, NULL);
sleep(5);
pthread_kill(cTid, SIGALRM);

the process's function:

void *executeApp(void *){
int returnValue = system("gedit");
}

Any thoughts on how I can launch an external program on another thread, let it execute for a shortwhile, then kill that thread with the parent thread other than this (since gedit in this case remains open)?

Thanks

 

[Crusty]

Threading on linux is definitely not my strong point, but I'm guessing that your thread is creating a new process for gedit so when you go to kill the thread, you are only killing the worker thread not the actual gedit process. So you would need to get the PID for your new process and kill that, and then stop your thread.

 

[Schadenfroh]

Originally posted by: Crusty
You would need to get the PID for your new process and kill that, and then stop your thread.

Would this best be accomplished by getting the list of processes on the system before the system("*"); command in the child thread and then comparing that list to the post execution process list and killing all processes spawned in the meantime?

In other words, how would the child thread be able to acquire the process id of the application that it launched using the system("") command?

Thanks for the quick reply!

 

[Crusty]

I'm sure someone else will know the best way, but most applications have a way for you to specify a pid file to store the pid when you start the process. So if you can set that, then you can just read that file in to get the PID.

edit:

So when you start a process with a & you get the pid output via stdout.

So like gedit& spits out [1] 12345 where 12345 is the pid

So with some basic stream redirection you can spit that pid right into a text file.

 

[Markbnj]

Every time I have seen this come up the recommendation has been to use fork(), which returns a pid you can then use to kill the process on request.

 

[Crusty]

Originally posted by: Markbnj
Every time I have seen this come up the recommendation has been to use fork(), which returns a pid you can then use to kill the process on request.

Ah yes. Much easier then trying to store the PID in a file

 

[Schadenfroh]

Originally posted by: Markbnj
Every time I have seen this come up the recommendation has been to use fork(), which returns a pid you can then use to kill the process on request.

The program that I am launching the programs from is fairly sizable, I was trying to use threads to reduce overhead.

Would the program launched by the system("*"); command using a child process be terminated along with the child process if terminated by the parent process?

 

[Markbnj]

Originally posted by: Schadenfroh

Originally posted by: Markbnj
Every time I have seen this come up the recommendation has been to use fork(), which returns a pid you can then use to kill the process on request.

The program that I am launching the programs from is fairly sizable, I was trying to use threads to reduce overhead.

Would the program launched by the system("*"); command using a child process be terminated along with the child process if terminated by the parent process?

I guess I am a little unclear on the goal, and I'm no Linux expert. But I don't think you can get a separate executable image running without starting a new process. You can point a thread at a function within your process, but to get another image loaded and running you need to create a new process. Otherwise you'd be loading an external executable image into your process address space, which has some interesting implications.

 

[tfinch2]

If you don't want to use fork (but I recommend you do), you can use the pidof command to query the pid of a process by name to kill it. You can also use killall to kill a process by name. I really don't recommend these methods because you might have a multiple instances of the same process and you might not want to kill all of them.

The reason your new process doesn't die when you kill the thread is because creating a new thread does not create a new parent. The child process lives on because the parent is still alive (the main thread of your process).

EDIT: Also, if you were to kill the parent, the child process would not die either. IIRC, all orphaned processes are inherited by the init process regardless of how their parent terminates.

In other words, just use fork to get the PID, and kill to get rid of it when you are done.

 

[Schadenfroh]

I don't think you can get a separate executable image running without starting a new process

I realize this, but I did not want to fork my original program and then use the child process to launch the new program (thus having three processes).

Originally posted by: tfinch2
The reason your new process doesn't die when you kill the thread is because creating a new thread does not create a new parent. The child process lives on because the parent is still alive (the main thread of your process).

That makes sense, thanks for explaining that to me. I guess I will use fork.

 

[hans007]

um...

maybe its different in linux, but if you are launching a seperate process i'm pretty sure that gets its own proces space. sure a process can have child threads, but can they have a child process?

in windows you would force terminate a process handle, which you can get from its pid . i'm sure at some level its pretty similar in linux.


i figure, when you run whatever it is in linux to start the process that call executes. i dont know exactly what that call sis but on windows its createprocess.


so that doesnt like block forever, it just runs and does it, and then if thats the only thing in your thread, the thread would get to the end , and the thread would shut off.

so running a thread, that launches a process, killing the thread (even if you say put a wait loop in it) would not shut off the process unless you coded a mechanism in to it to do that.

 

[Schadenfroh]

After digging through my textbook from last semester and digging around through the documentation of some of the libraries, I think I have it working the way that I want it to work. Here is what I did and it "appears" to work (launches the program and allows it to execute and then kills it after 5 sec.).

Libraries:

#include <sys/signal.h>
#include <sys/shm.h>
#include <sys/stat.h>

Function:

int segment_id;
pid_t* sharedMem;
const int size = 4096;

segment_id = shmget(IPC_PRIVATE, size, S_IRUSR | S_IWUSR);
sharedMem = (pid_t *) shmat(segment_id, NULL, 0);


pid_t cTid;


cTid = fork();

if (cTid < 0){
cerr << "Forking failed in analyzeApp" << endl;
} else if (cTid == 0){ //child process
*sharedMem = getpid(); //stores the spawned process' id into the shared variable
execvp("/home/schadenfroh/NetBeansProjects/PE_Analyzer/Test3.exe", NULL); //launches the application

} else{ //parent process
sleep(5); //waits for 5 sec.
kill((*sharedMem),SIGTERM); //kills the child process

}

 

[hans007]

Originally posted by: Schadenfroh
After digging through my textbook from last semester and digging around through the documentation of some of the libraries, I think I have it working the way that I want it to work. Here is what I did and it "appears" to work (launches the program and allows it to execute and then kills it after 5 sec.).

Libraries:

#include <sys/signal.h>
#include <sys/shm.h>
#include <sys/stat.h>

Function:

int segment_id;
pid_t* sharedMem;
const int size = 4096;

segment_id = shmget(IPC_PRIVATE, size, S_IRUSR | S_IWUSR);
sharedMem = (pid_t *) shmat(segment_id, NULL, 0);


pid_t cTid;


cTid = fork();

if (cTid < 0){
cerr << "Forking failed in analyzeApp" << endl;
} else if (cTid == 0){ //child process
*sharedMem = getpid(); //stores the spawned process' id into the shared variable
execvp("/home/schadenfroh/NetBeansProjects/PE_Analyzer/Test3.exe", NULL); //launches the application

} else{ //parent process
sleep(5); //waits for 5 sec.
kill((*sharedMem),SIGTERM); //kills the child process

}

that seems like the wrong way to do it.



fork returns 0 if you are the child, or the pid if you are the parent. so why do the shared data and such, to get the pid, when the parent already has it

in your code above you already have the pid in cTid.... so why are you sharing memory you can just go

else{ //parent process
sleep(5); //waits for 5 sec.
kill((cTid),SIGTERM); //kills the child process

instead of sharing memory and having to deal with possible race conditions on your now un mutexed shared memory.


also this doesnt really "launch a process" it launches a copy of your current process not a different process.

 

[Schadenfroh]

Originally posted by: hans007
you can just go

You are correct, that does work and eliminates the need for the shared variable. I assumed incorrectly about the pid that fork returned.

 

[Cerebus451]

Not sure what is going on with your original thread creation, but I dug through some old code I had that needed to do something similar. I couldn't use fork because the main program was large and I didn't need to create another copy of it just to launch another process. The attached code is the basics of what I use. The main program creates a worker thread, which runs the command (which itself creates another thread for the program to run in). The worker thread waits for either the command to finish, or for the main program to tell it to terminate early. The extra sleep I have in the main program is just there to make sure that the gedit command is exiting from the thread cancel, and not from the main program terminating.

The worker thread I have doesn't do a whole lot. In the program this code was pulled from the worker threads are doing a lot more, possibly running several commands before exiting, just wanted to create something basic to show how it works.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <pthread.h>

#define TERMINATED -1
#define SUCCESS 0

typedef struct
{
char * cmd;
char active;
int retCode;
} COMMAND_STRUCT;

static void * ExecuteCommand (void * lpParameter)
{
int old;
COMMAND_STRUCT * ptr = (COMMAND_STRUCT *) lpParameter;

pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, &old);
ptr->retCode = system (ptr->cmd);
ptr->active = 0;

return 0;
}

extern char RunCommand (char * cmd,
char * threadTerm,
int * retCode)
{
pthread_t thread;
COMMAND_STRUCT parm;

parm.cmd = cmd;
parm.active = 1;
pthread_create (&thread,
NULL,
ExecuteCommand,
&parm);

while (parm.active)
{
if (*threadTerm)
{
pthread_cancel (thread);
parm.active = 0;
}
sleep (2);
}
*retCode = parm.retCode;
if (*threadTerm)
{
return TERMINATED;
}
else
{
return SUCCESS;
}
}

static void * workerThread (void * lpParameter)
{
int ret;
RunCommand ("gedit", lpParameter, &ret);
}

int main ()
{
pthread_t thread;
char term = 0;
pthread_create (&thread, NULL, workerThread, &term);
sleep(5);
term = 1;
sleep(5);
}

 

[degibson]

It sounds to me like you want to take Markbnj's advice and use fork() (or vfork()), followed by some form of exec() (e.g., execlp). Then you have exactly two processes... no superflous threads or anything. You can also try popen() if you want to redirect output to a file.

Threading, system(), etc aren't quite what you need.

 

[Schadenfroh]

Thanks guys, one last question. I have yet to see any guides to redirecting the debug console output (in order to capture the text). Almost everyone says to use this console argument to redirect it to a file. But, they do not seem to work with the exec() commands. Any idea how to capture a large amount of text from the debug console output of a program launched by the exec command since "myprogram 2> output.txt" is not an option?

 

[Crusty]

Just have your program execute a script that does it for you.

 

[KCfromNC]

Since you're not running the child via a shell, you won't be able to use the command line redirection stuff that shells provide. You'll need to duplicate what the shells are doing in your own program - look into pipe() and dup()/dup2(). Numerous examples are easy to find via google.

 

[degibson]

Use popen.