First of all hello, (this is my first post)

I'm using a daemon which takes requests (fetces rows) from a database and then starts an rsync (remote synchronization tool provided by samba) with the exec() command. I want to add a feature so that the daemon can stop (kill -STOP) an rsync process and then continue later (kill -CONT).

The Tree is like this:

-parent
\_forked-process (known pid)
\__Rsync-process (executed using exec command, unknown pid)

My problem is that after executing the exec command inside the forked-process the pid of the rsync-process is unknown (exec() does not return the pid) so I don't know it's value to stop it later...

Any help appreciated
Thanks for your time & sorry for my bad english

You might try to use "setpgrp" after "fork" and before "exec" to set the process group of the child process.

Then you can use "killpg" to send a signal to every child in that group.

Exec doesn't create a new pid. The _only_ function in unix that causes a new pid to be created is fork. So you already know the pid.

Unless I am sadly mistaken, exec replaces the calling process with the one that you are executing. The call returns only if it does not succeed.

So, if you fork a child process which then execs another program-file, the PID of the child has not changed. It has ceased to be an instance of the original parent-process and has become an instance of the program that it execed.

So your diagram is incorrect. There are never three layers.

rsync might fork even more processes to distribute the work to be done (or maybe threads, depending on what they share).

This is what I assumed from the diagram, and thus the suggestion to give a different process group id to the child.

This is correct.. I'm trying to apply your solution

Create a pipe with 'pipe', fork the process with 'fork', replace standard output of the forked process with the input pipe descriptor using 'dup2', then 'execv' your new process. The exec'ed program inherits the replaced stdout, which will print to the pipe which the original process has a descriptor for.
http://www.gnu.org/software/libc/man...reating-a-Pipe
http://www.gnu.org/software/libc/man...ng-Descriptors
ta0kira

PS Do the same thing with stdin if you want to send info TO the process; then you can use 'fgets_unlocked' to check for a signal periodically without freezing the thread waiting for input.
http://www.gnu.org/software/libc/man...tml#Line-Input