I already read the man page of the pidfile function family. But I don't really understand it. What is the correct usage? Is there a more elaborate example available? I think I understand pidfile_open. But when should I call pidfile_write and prdfile_close? From which process? Parent or child? What parameters do I have to pass to those functions? I propably lack some *nix fundamentals I guess.
Update:
Below you see the example from man pidfile. Why do they fork twice? Why pidfile_close? When I call pidfile_close I can start another daemon. Isn't that unwanted?
struct pidfh *pfh;
pid_t otherpid, childpid;
pfh = pidfile_open("/var/run/daemon.pid", 0600, &otherpid);
if (pfh == NULL) {
if (errno == EEXIST) {
errx(EXIT_FAILURE, "Daemon already running, pid: %jd.",
(intmax_t)otherpid);
}
/* If we cannot create pidfile from other reasons, only warn. */
warn("Cannot open or create pidfile");
}
if (daemon(0, 0) == -1) {
warn("Cannot daemonize");
pidfile_remove(pfh);
exit(EXIT_FAILURE);
}
pidfile_write(pfh);
for (;;) {
/* Do work. */
childpid = fork();
switch (childpid) {
case -1:
syslog(LOG_ERR, "Cannot fork(): %s.", strerror(errno));
break;
case 0:
pidfile_close(pfh);
/* Do child work. */
break;
default:
syslog(LOG_INFO, "Child %jd started.", (intmax_t)childpid);
break;
}
}
pidfile_remove(pfh);
exit(EXIT_SUCCESS);
The problem is that you want to give an error message before the daemon is spawned, and that you know the PID file after the daemon is spawned.
So you typically do the pidfile_open before the fork, which gives you a possibility to give an error message. After you forked, you know the pidfile and you can do pidfile_write.
You do the pidfile_open(3) before you go into background, so you can immediately report any problems. You don't write PID just yet, because your PID will change after daemon(3). pidfile_open(3) only locks the pidfile. After daemon(3) you can call pidfile_write(3) as you now have your final PID (daemon(3) forks internally). In the main process you cannot call pidfile_close(3), because this is the whole idea - by keeping the pidfile open and locked you let others know that you are still alive. The second fork is totally optional. It illustrates common behaviour that daemons spawn child/worker processes. If you don't use them you don't need this fork(). This fork() is there only to show that in such worker process you should close the pidfile, so it is only kept open and locked by the main process and not by the child.
Related
So I am confused by the behavior of my C program. I am using the construct,
int pid = fork();
if (pid == 0) {
if(file_upload_script_path) {
rc = execv(file_upload_script_path, args);
if(rc == -1) {
printf("Error has occured when starting file_upload.exp!\n");
exit(0);
}
} else {
printf("Error with memory allocation!\n");
}
}
else {
printf("pid=%d\n", pid);
}
To fork the process and run a script for doing file upload. The script will by itself terminate safely, either by finishing the upload or failing.
Now, there was a problem with the script path, causing execv to fail. Here I noted the child process will terminate successfully if execv finishes, but in case it fails (r==-1) and I exit the process, it will become a zombie. Anyone knows why this happens?
Note here, I know why the child-process becomes a zombie. What I am confused about is why the process not becomes a zombie if execv works.
EDIT:
I got a question about errno and the cause of the error. The cause of the error is known. There were a problem with the build process, so the path of the script were another than expected.
However, this may happen again and I want to make sure my program does not start spawning zombies when it does. The behavoir where zombies are created in some situations and not others are very confusing.
BR
Patrik
If you don't want to create zombies, your program has to reap zombie processes no matter if they call execv or not call it or no matter if the execv call succeeds. To reap zombie processes "automagically" handle SIGCHLD signal:
void handle_sigchld(int sig) {
int saved_errno = errno;
while (waitpid((pid_t)(-1), 0, WNOHANG) > 0) {}
errno = saved_errno;
}
int main() {
signal(SIGCHLD, handle_sigchld);
// rest of your program....
}
Inspired (no... ripped off) from: this link.
Or maybe you want only to reap only this specified child, because later you want to call fork() and handle childs return value. Then pass the returned pid from fork() in your parent to the signal handler and wait on this pid in sigchld if needed (with some checking, ex. if the pid already finished then ignore future SIGCHLD etc...).
In this scenario, when the execv fails, the child process is killed. The fun part, I think is what happens when you call exec family of functions.
The exec family of functions replaces the current image of the process with the new image of the binary you are about to exec.
So, whatever code was will not remain - and the error in your script would cause its death.
Here, the parent needs to listen on the death of the child process using wait flavour of functions (read: waitpid).
When you say that there's problem in the script, it means that the execv actually succeeded in creating the new image; but the latter failed of its own accord.
This is what I think is happening...
If the printf of if (rc==-1) is being executed, then perhaps changing exit(0) to _exit(0) should take care of it.
I would like to create a new process using fork and then use excl to start a web browser with a url.
Im not too familiar with fork and excel so any help would be appreciated.
thanks
EDIT:
this is my code but i don't think its right
if(fork() == 0) {
execl (url,0);
printf("Route opened in brwoser\n");
} else {
printf("Route cannot be opened.\n");
}
Read the manual pages of these calls first:
man 2 fork
man 3 execl
The syscall fork() makes a copy of the process and returns in both, returning the child process ID in the parent and zero in the child. If it returns a negative number, it means it's failed.
pid_t pid = fork();
if (pid < 0)
printf("Fork failed\n");
else if (pid > 0) /* Here comes the parent process */
printf("Fork successful\n");
else /* Here comes the child process */
...
On the other hand execl() does not return at all. It throws away your program, and replaces it with image of the one specified in its arguments in the same process.
If execl() returns, it's an error. It probably did not find the program you specified.
Its arguments are the called program (an URL is not a program) and its arguments.
...
else { /* Here comes the child process */
execl("/usr/bin/firefox", "/usr/bin/firefox", "example.com", (char*)NULL);
printf("Could not execute Firefox\n");
}
In my parent process, I have created a child process which executes system("find / -print").
From inside the parent, when I try to kill this child process using kill(childProcPID, SIGTERM), it doesn't get terminated immediately. system command keeps on printing the output on console.
Here is the example code:
int main(void) {
pid_t childProc = fork();
switch (childProc) {
case -1:
perror("fork() error");
exit(EXIT_FAILURE);
case 0:
system("find / -print");
printf("if I use kill(pid, SIGTERM) control doesnt reach here");
exit(EXIT_SUCCESS);
default:
;
int i = 500000;
//No a great way to put sleep
//but its just temp
while (i != 0) {
--i;
}
kill(childProc, SIGTERM);
break;
}
printf("Exit!!!!!!");
return EXIT_SUCCESS;
}
Please let me know what I am doing wrong or is the right way to kill a child ?
The system function will itself create a child process to execute the command (and then block until that child process terminates). What you've done is kill the child process that calls system, but not the child process that system has spawned.
try setting the session id and killing the process group instead (man 2 kill)
int main(void) {
pid_t childProc = fork();
switch (childProc) {
case -1:
perror("fork() error");
exit(EXIT_FAILURE);
case 0:
setsid();
system("find / -print" );
printf("if I use kill(pid, SIGTERM) control doesnt reach here");
exit(EXIT_SUCCESS);
default:
sleep(1);
kill(childProc*-1, SIGTERM);
break;
}
printf("Exit!!!!!!");
return EXIT_SUCCESS;
}
this more or less works. The caveat is that there's a bit of a race in that the parent has to give the child time to setsid(), hence the sleep.
Hope that helps.
First, you should be checking the result that you get back from kill() -- if you get 0 back, the operation succeeded. If you get -1 back, though, check the global variable errno to see what the problem was.
If the signal is being sent successfully, the only thing you can do is make sure that you're sending the signal that you intend. As #Till points out in a comment, sending SIGKILL instead of SIGTERM will be more effective because the OS handles the former and the target process cannot ignore it.
In any case, realize that interacting with other processes is usually an asynchronous process -- the target process probably won't be terminated by the time kill() returns no matter what you do.
I am trying to create a simple client/server program that allows the client to connect to the server using a TCP socket and then allows the user to issue system calls form the client side to the server side and return the reply to the user. For example:
Client issues: ls
Server will find ls in /usr/bin or w/e and then execute it using execve()
I will also have something liks lls, or lmkdir, ect..which will issue the system calls on the client side.
The problem is my execve() is not appearing to run correctly because 'ls' or any other command is not actually being called. I have done this same kind of program before with only a local side (no server or anything) and execve() worked fine. Here is some code:
pid = fork();
if(pid){ // Child
printf("child wait");
pid = wait(&status);
printf("Child dead\n");
}else{ // Parent
if(execPath){
execve(execPath, arglist, env);
printf("Command Complete\n");
}
}
For some reason the printfs in the child section of the PID statement are not executing at all. I do not think the system is actually ever forking a process. Is there something special I would have to do to make this work since it is a client/server type of program or should it work exactly the same?
Thanks
exactly, execve does not fork. It replaces current image with the one specified as its argument and starts from its start (i.e. main()). It never returns to your origial program.
You probably want to use system() in your use case.
There are several problems in the code:
fork() returns pid for the parent and zero for the child. So parent runs the true branch of the if. And child runs the else branch. Swap those comments.
The stdout is line buffered. Add new line (\n) to printf which is before the wait. Or else you don't see the printout before waiting is done and 2nd printf is under call.
Be sure that child will exit also in error cases, or else the child will run the code of parent, and parent is still waiting exit of the child.
execve does not return if it success. It will return, if it fails.
So, fixed code could be something like that:
pid = fork();
if(pid){ // Parent
printf("child wait\n");
pid = waitpid(pid, &status, 0);
printf("Child dead\n");
}else{ // Child
if(execPath){
execve(execPath, arglist, env);
printf("execve failed!\n");
}
_exit(1);
}
Or you could use system(3).
Since the child process has not spawned any children of its own, the wait() call is unlikely to return without some other external event (like a signal interrupting the call). You should have the parent wait on the child process instead.
Note that fork() may fail, and you should account for that. Also note that if execve succeeds, it won't return. So, the print statement after it should indicate failure if it is to print anything at all.
Using system() probably would not save you the fork, since you are likely to want the output of the command to be directed to the socket associated with the connected client. But, your code is missing the steps that would allow the output to flow to the client.
switch ((pid = fork())) {
case -1: /* todo: handle error */
break;
case 0: /* child */
dup2(socket, 0); /* todo: check return value */
dup2(socket, 1); /* todo: check return value */
dup2(socket, 2); /* todo: check return value */
close(socket); /* todo: check return value */
execve(...);
/* todo: handle failure */
exit(EXIT_FAILURE);
default: /* parent */
if (pid != waitpid(pid, 0, 0)) {
/* todo: handle error */
}
}
I'm creating background processes in C using fork().
When I created one of these processes, I add its pid to an array so I can keep track of background processes.
pid = fork();
if(pid == -1)
{
printf("error: fork()\n");
}
else if(pid == 0)
{
execvp(*args, args);
exit(0);
}
else
{
// add process to tracking array
addBGroundProcess(pid, args[0]);
}
I have a handler for reaping zombies
void childHandler(int signum)
{
pid_t pid;
int status;
/* loop as long as there are children to process */
while (1) {
/* get zombie pids */
pid = waitpid(-1, &status, WNOHANG);
if (pid == -1)
{
if (errno == EINTR)
{
continue;
}
break;
}
else if (pid == 0)
{
break;
}
/* Remove this child from tracking array */
if (pid != mainPid)
cleanUpChild(pid);
}
}
When I create a background process, the handler is executing and attempting to clean up the child before I can even make the call to addBGroundProcess.
I'm using commands like emacs& which should not be exiting immediately.
What am I missing?
Thanks.
You're right, there is a race condition there. I suggest that you block the delivery of SIGCHLD using the sigprocmask function. When you have added the new PID to your data structure, unblock the signal again. When a signal is blocked, if that signal is received, the kernel remembers that it needs to deliver that signal, and when the signal is unblocked, it's delivered.
Here's what I mean, specifically:
sigset_t mask, prevmask;
//Initialize mask with just the SIGCHLD signal
sigemptyset(&mask);
sigaddset(&mask, SIGCHLD);
sigprocmask(SIG_BLOCK, &mask, &prevmask); /*block SIGCHLD, get previous mask*/
pid = fork();
if(pid == -1)
{
printf("error: fork()\n");
}
else if(pid == 0)
{
execvp(*args, args);
exit(0);
}
else
{
// add process to tracking array
addBGroundProcess(pid, args[0]);
// Unblock SIGCHLD again
sigprocmask(SIG_SETMASK, &prevmask, NULL);
}
Also, I think there's a possibility that execvp could be failing. (It's good to handle this in general, even if it's not happening in this case.) It depends exactly how it's implemented, but I don't think that you're allowed to put a & on the end of a command to get it to run in the background. Running emacs by itself is probably what you want in this case anyway, and putting & on the end of a command line is a feature provided by the shell.
Edit: I saw your comments about how you don't want emacs to run in the current terminal session. How do you want it to run, exactly - in a separate X11 window, perhaps? If so, there are other ways of achieving that.
A fairly easy way of handling execvp's failure is to do this:
execvp(*args, args);
perror("execvp failed");
_exit(127);
Your code just catches the exit of the child process it fork'ed, which is not to say that another process wasn't fork'ed by that child first. I'm guessing that emacs in your case is doing another fork() on itself for some reason, and then allowing the initial process to exit (that's a trick daemons will do).
The setsid() function might also be worth looking at, although without writing up some code myself to check it I'm not sure if that's relevant here.
You should not be using the shell with & to run background processes. If you do that, they come out as grandchildren which you cannot track and wait on. Instead you need to either mimic what the shell does to run background processes in your own code, or it would probably work just as well to close the terminal (or rather stdin/out/err) and open /dev/null in its place in the child processes so they don't try to write to the terminal or take control of it.