I am creating a simple Linux command shell in C. I am having trouble understanding where my code is having problems. "commands" is a list of strings of Linux commands that I want to be executed concurrently as the children processes of one parent. When all are done executing, I want the parent to exit the function. However, when I call exit(0), the for loop continues and parses the current command again, causing the args to be executed again in execvp. Am I using fork() and wait() correctly here? I have tried using waitpid() as well with no luck.
void executeShell(char** commands){
char **arr = commands;
char *c;
pid_t pid, wpid;
int status = 0;
for (c = *arr; c; c=*++arr){
// printf("%d-\n", strcmp(command, "exit"));
if (strcmp(c, "exit") == 0){
EXIT = 1;
return;
}
printf("Running command \'%s\'...\n", c);
char** args = parseStringToTokenArray(c, " ");
free(args);
/* fork and execute the command */
pid = fork();
if(pid < 0){
perror("fork() error\n");
return;
}
/* child process executes command */
else if (pid == 0){
/* 'cd' is not a part of /bin library so handle it manually */
if (strcmp(args[0], "cd") == 0){
changeDirectory(args[1]);
}
else if (strcmp(args[0], "sdir") == 0){
searchDirectory(args[1]);
}else{
/* parse commands with arguments */
execvp(args[0], args);//execute the command
}
exit(0);// <-----command is finished, so why no exit?
}
}
/* wait for children to complete */
while((wpid = wait(&status)) > 0);
}
If execvp succeeds, the entire child process address space is replaced by the program invoked by execvp(). This means that the exit(0) will only ever be invoked following your two special cases i.e. cd and sdir. As far as your code is concerned execvp() should never return, unless there is an error.
A further problem is that you free args immediately after allocating it and then go on to use it in your child processes. This is undefined behaviour.
The only problem I see with your wait code is that, if any of the children block waiting for user input, the parent will block waiting for the child to exit.
The cd code, has no effect on any process except the child in which it is executed. The parent's current directory is not affected. As you state in the comments, this can bet fixed by handling cd in the parent without forking.
Related
I'm making a shell in C for a school project that is capable of running processes in parallel if it is commanded to do so.
This is the loop of the shell application that waits for commands:
while (1) {
action = parseShellArgs();
if (action == 1) {
printf("Exiting...\n");
break;
} else if (action == 0) {
int pid = fork();
if (pid < 0) {
printf("Failed to fork\n");
} else if (pid == 0) {
(*NUM_PROCESSES_RUNNING)++;
printf("There are %d processes running\n", *NUM_PROCESSES_RUNNING);
char * solverArgs[] = {"a", shellArgs[1], NULL}; // first element is placeholder for argv[0]
execv("CircuitRouter-SeqSolver", solverArgs);
exit(0);
} else if (pid > 0) {
if (*NUM_PROCESSES_RUNNING >= MAXCHILDREN) {
printf("All processes are busy\n");
continue;
}
int status, childpid;
wait(&status);
childpid = WEXITSTATUS(status);
(*NUM_PROCESSES_RUNNING)--;
printf("There are %d processes running\n", *NUM_PROCESSES_RUNNING);
(void)childpid; // suppress "unused variable" warning
} else {
printf("Wait what\n");
}
} else {
printf("Oops, bad input\n");
}
}
Please do disregard the constants being incremented and decremented.
Now, this only works partially. Whenever I give it a command to create another process and run another program (condition action == 0, this has been tested and works), the fork happens and the program is correctly executed.
However, I cannot fork multiple times. What I mean by this is: the program forks and the child executes as instructed in the execv call. The problem is that instead of the parent process then goes back to expecting input to possibly fork again, it waits for the child process to finish.
What I am trying to make this cycle do is for the parent to always be expecting input and forking as commanded, having multiple children if necessary. But as I explained above, the parent gets "stuck" waiting for the single child to finish and only then resumes activity.
Thank you in advance.
Edit: I have experimented multiple combinations of not waiting for the child process, using extra forks to expect input etc.
From man wait.2
The wait() system call suspends execution of the calling process until
one of its children terminates.
Your program gets stuck because that's what wait does. Use waitpid instead with WNOHANG.
waitpid(pid_child, &status, WNOHANG);
doesn't suspend execution of the calling process. You can read the waitpid man page to find out the return values and how to know if a child terminated.
I am trying to terminate my program which takes a line that is full of commands from a file and then process each command using execvp
However,Whenever I encounter quit, I want to immediately exit processing the commands and ignore all other commands that are coming after it.
I tried to do this the following way using exit()
for(int i =0;i < numOfCommands;i++)
{
childPid = fork();
if(childPid == 0)
{
if(execvp(commands[i].cmd[0],commands[i].cmd) == -1)
{
/*if(strcmp(commands[i].cmd[0],"quit"))
{
done = true;
return;
}*/
if(strcmp(commands[i].cmd[0],"quit")==0)
{
printf("Quit command found ! \n Quitting .");
done = true;
//return;
exit(0);
}
printf("Command %s is unknown \n", commands[i].cmd[0]);
}
}
else
{
//parent process
wait(&child_status);
}
}
}
And this happens inside of the child process, after forking of course. But the problem is that my program keeps processing the remaining commands that comes after quit before exiting the program !
You can use kill(2) to send a signal to the process group. You can do this in the parent or any of the children.
int kill(pid_t pid, int sig);
If pid equals 0, then sig is sent to every process in the process group of the calling process.
For example:
kill(0, SIGTERM);
I think a better way to deal with this is to check for the quit command in the parent process before forking the child.
But if you want to do it in the child, you can send a signal to the parent.
kill(getppid(), SIGUSR1);
The parent process will need to establish a signal handler for SIGUSR1 that cleans everything up and exits. Or you could send a signal like SIGINT, whose default action is to kill the process, but it's better to implement a clean exit.
Also, in your code, you should check for the quit command before calling execvp. Otherwise, if there's a quit program in the user's path, it will never match your built-in quit, since execvp will succeed and not return.
I'm trying to write basic shell program that will manage job control with background processes. I understand to send a process to the background you call fork(), but don't wait for it in the parent. However, I also know you need to call waitpid() with the WNOHANG option to get the status of a process that has finished executing. My question is when and how to call the waitpid() in my code in order to know when a child finishes. Here's what I have so far for just executing a process in the background:
for (;;) {
char buff[PATH_MAX + 1];
char *cwd = getcwd(buff, PATH_MAX + 1);
printf("%s/", cwd);
char *cmd = readline("shell>"); //This code just sets up a cmd prompt
if (strcmp(tokList[0], bgCmd) == 0) {
//If the user inputs 'bg' then run the command in the background parent
pid_t child_pid = fork();
if (child_pid == 0) {
execvp(bgTokList[0], bgTokList); // This array contains just the arguments to be executed
perror("execvp");
return -1;
} else {
//parent
}
}
}
When a child process has completed, the parent will receive the signal SIGCHLD. Your signal handler can then reap the status.
Using an existing example, you can modify it for your own needs.
I am writing a simple C program to create my own shell. It takes in input as commands and executes them. But when I try to execute a process in background( i.e. I fork a process from parent. The parent won't wait for the child process to finish, it just goes on to take more input commands while the child process runs in the background.) The execvp does execute the command but then gives a segmentation fault immediately.
Can you help me? I'll post my part of the code which I think is relevant. Let me know if you need to know anything more, i'll edit my question accordingly.
while(1){
pid = fork();
if(pid == 0)
executeCommand(info);
else
{
if(info->boolBackground ==1)
{
waitpid(pid , status , WNOHANG);
}
else
wait(NULL);
}
} //Info contains the command to be executed and it's arguments.
Here is me executeCommand function:
void executeCommand(parseInfo * info)
{
FILE *infile, *outfile;
struct commandType * com;
char * cmd;
int i , status;
cmd = (char*)malloc(1024);
strcpy(cmd , info->CommArray[0].command);
if(info->boolOutfile == 1)
{
outfile = fopen(info->outFile, "w");
dup2(fileno(outfile), 1);
}
if(info->boolInfile == 1)
{
infile = fopen(info->inFile, "r");
dup2(fileno(infile), 0);
}
status = execvp(cmd , info->CommArray[0].VarList); //VarList contains the arguments
if(status == -1){
printf("%s\n",strerror(errno));}
exit(0);
}
When I give an input command: ls &
(& means that ls should be executed in background.)
It forks a child process which executes ls and prints the list of files/directories in the directory and then gives segmentation fault. Can you spot the error? I tried running execvp in background with simply ls command. It also lead to a segmentation fault.
Yes, as Mark Plotnick pointed out in a comment, you'll need probably need &status. I'd use &info->status. Also, if you do detached jobs, you need to maintain a list of their info objects and do a waitpid loop on them:
forall (info in detached_detach_job_list) {
pid = waitpid(info->pid,&info->status,WNOHANG);
if (pid > 0) {
report_status(info);
remove_job_from_list(info);
}
}
Hopefully, the code frag you gave for your outer loop does something like this.
Also, I might not do "wait(NULL)" for a foreground. I'd treat it similarly to a detached job. Consider a case where a user does:det1 &
det2 &
...
det9000 &
run_long_30_minute_job
Because your shell is doing a hard wait on the foreground, it can't reap the detached jobs as they finish and you'll end up with zombie processes. Do the list/loop approach, just don't give user a prompt until the foreground completes (e.g. it's in the list, it's just the one with the background flag cleared). In other words, call the list something like child_list to denote all child processes, not just background. Put a sleep in the outer loop. Or, attach to SIGCHLD and do a single long sleep
I am currently trying to run a fork function in C where in the child section of the code,
I am trying to execute a command using exacvp, but before the execution I am trying a printf function which never executes. I ran this in debug and I have noticed that the pid is never assigned 0. I did try a simple fork example on a separate project and it worked smoothly. Does anyone have an idea why the child section never executes?
int startProcesses(int background) {
int i = 0;
while(*(lineArray+i) != NULL) {
int pid;
int status;
char *processName;
pid = fork();
if (pid == 0) {
printf("I am child");
// Child Process
processName = strtok(lineArray[i], " ");
execvp(processName, lineArray[i]);
i++;
continue;
} else if (!background) {
// Parent Process
waitpid(pid, &status, 0);
i++;
if(WEXITSTATUS(status)) {
printf(CANNOT_RUN_ERROR);
return 1;
}
} else {
i++;
continue;
}
}
return 0;
}
stdio files are flushed on program's exit, but execvp directly replaces the process with another image, bypassing the flush-at-exit mechanism and leaving the I am child message in memory never to be sent to the screen. Add an explicit fflush(stdout) before execvp, or end your string with \n so that it is automatically flushed when running on a TTY.
Note that execvp never exits, and if it does, it is because it has failed to execute the new process. At that point, the only thing the child can do is to report an error and call _exit(127) (or similar exit status). If the child continues, an incorrectly configured command name will cause it to execute the rest of the parent's loop in parallel with the parent. This process will continue for other descendants, effectively creating a fork bomb that can grind your system to a halt.