Tag Info

Hot answers tagged

40

It's to simplify the interface. The alternative to fork and exec would be something like Windows' CreateProcess function. Notice how many parameters CreateProcess has, and many of them are structs with even more parameters. This is because everything you might want to control about the new process has to be passed to CreateProcess. In fact, CreateProcess ...


30

The short answer is, fork is in Unix because it was easy to fit into the existing system at the time, and because a predecessor system at Berkeley had used the concept of forks. From The Evolution of the Unix Time-sharing System (relevant text has been highlighted): Process control in its modern form was designed and implemented within a couple of days. ...


18

The traditional way of daemonizing is: fork() setsid() close(0) /* and /dev/null as fd 0, 1 and 2 */ close(1) close(2) fork() This ensures that the process is no longer in the same process group as the terminal and thus won't be killed together with it. The IO redirection is to make output not appear on the terminal.


18

The new process will be created within the fork() call, and will start by returning from it just like the parent. The return value (which you stored in retval) from fork() will be: 0 in the child process The PID of the child in the parent process -1 in the parent if there was a failure (there is no child, naturally) Your testing code works correctly; it ...


17

The answer is more or less that ls is an external executable. You can see its location by running type -p ls. Why isn't ls built into the shell, then? Well, why should it be? The job of a shell is not to encompass every available command, but to provide an environment capable of running them. Some modern shells have echo, printf, and their ilk as builtins, ...


17

[I'll repeat part of my answer from here.] Why not just have a command that creates a new process from scratch? Isn't it absurd and inefficient to copy one that is only going to be replaced right away? In fact, that would probably not be as efficient for a few reasons: The "copy" produced by fork() is a bit of an abstraction, since the kernel uses a ...


16

It's not that difficult to decipher in fact. This piece of code just defines a function named : which calls two instances of itself in a pipeline: :|:&. After the definition an instance of this function is started. This leads to a fast increasing number of subshell processes. Unprotected systems (systems without a process number limit per user) will be ...


14

For a daemon, what you want is a process that has no tie to anything. At the very least, you want it to be in its own session, not be attached to a terminal, not have any file descriptor inherited from the parent open to anything, not have a parent caring for you (other than init) have the current directory in / so as not to prevent a umount... To detach ...


13

First of all, every time you execute a command, you shell will fork a new process, regardless of whether you run it with & or not. & only means you're running it in the background. Note this is not very accurate. Some commands, like cd are shell functions and will usually not fork a new process. type cmd will usually tell you whether cmd is an ...


13

Man pages are usually terse reference documents. Wikipedia is a better place to turn to for conceptual explanations. Fork duplicates a process: it creates a child process which is almost identical to the parent process (the most obvious difference is that the new process has a different process ID). In particular, fork (conceptually) must copy all the ...


13

The Bash Reference Manual states: Builtin commands are necessary to implement functionality impossible or inconvenient to obtain with separate utilities. That is, shells are designed to only include built-in commands if: Required by the POSIX standard Commands that require access to the shell itself, such as job control built-ins Commands that are ...


10

I thought that fork() creates a same process, so I initially that that in that program, the fork() call would be recursively called forever. I guess that new process created from fork() starts after the fork() call? Yes. Let's number the lines: int main (int argc, char **argv) { int retval; /* 1 */ ...


10

This fork bomb always reminds me of the something an AI programming teacher said on one of the first lessons I attended "To understand recursion, first you must understand recursion". At it's core, this bomb is a recursive function. In essence, you create a function, which calls itself, which calls itself, which calls itself.... until system resources are ...


8

Is it ever useful to do "nohup ... &" - yes. If you just start a process "in the background" with '&', that new process still has membership in the original shell's "process group". If that shell or the process group gets certain signals (SIGHUP, for example), by default they exit. This means that if you run a process with '&' from a shell ...


8

When a child is forked then it inherits parent's file descriptors, if child closes the file descriptor what will happen ? It inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa. If child starts writing what shall happen to the file at the parent's end ? Who ...


8

The idea behind threads and processes is about the same: You fork the execution path. Otherwise threads and processes differ in things like memory. I.e. processes have different VM space while threads share whatever existed before the split. Underlying both threading and forking work by using the clone() call (man 2 clone): Unlike fork(2), clone() ...


7

You should try setsid(1). Use it like you'd use nohup: setsid command_which_takes_time input > output This (as per the setsid(2) manpage), does a fork(2), an _exit(2) of the parent process, then the child process calls setsid(2) to create a new process group (session). You can't kill that by logging out, and it's not part of the Bash job control ...


7

Yes. Forking is spelled &: echo child & echo parent What may be confusing you is that $$ is not the PID of the shell process, it's the PID of the original shell process. The point of making it this way is that $$ is a unique identifier for a particular instance of the shell script: it doesn't change during the script's execution, and it's ...


7

No, fork is not "recursive" in the traditional meaning of recursion. A call to fork() duplicates the current process so it "returns twice". For the child process, the return value is 0, and for the parent the return value is the child PID. fork() does not restart main - that would be more like fork followed by exec. Your program works like this. First ...


6

As seen earlier, vfork does not allow the child process to access the parent's memory. exit is a C library function (that's why it's often written as exit(3)). It performs various cleanup tasks such as flushing and closing C streams (the files open through functions declared in stdio.h) and executing user-specified functions registered with atexit. All these ...


6

In the C API, system calls return a negative value to indicate an error, and the error code in errno gives more information on the nature of the error. Your man page should explain the possible errors on your system. There are two standard error codes: EAGAIN indicates that the new process cannot be created due to a lack of available resources, either ...


6

Try creating subshell with (...) : ( command_which_takes_time input > output ) & Example: ~$ ( (sleep 10; date) > /tmp/q ) & [1] 19521 ~$ cat /tmp/q # ENTER ~$ cat /tmp/q # ENTER (...) #AFTER 10 seconds ~$ cat /tmp/q #ENTER Wed Jan 11 01:35:55 CET 2012 [1]+ Done ( ( sleep 10; date ) > /tmp/q )


6

With command & Your process will be killed by a SIGHUP signal when the parent dies. Sysadmins have access to some workaround, though. On a bash system, you can use: (trap '' HUP; command) & This opens a subshell, traps the HUP signal with an empty handler and ampersand/forks it. Output might still get redirected to the wrong tty. Or get lost. ...


6

Try the psacct package (GNU accounting), it should do just about everything you need, once installed and enabled (accton), then lastcomm will keep report on user processes (see also sa and dump-acct). See this for reference: User's executed commands log file You might need to upgrade the version to log PID/PPID, see ...


5

Stdin, stdout and stderr are inherited from the parent process. It's up to the child process to change them to point to new files if that is needed. From the fork(2) man page: * The child inherits copies of the parent's set of open file descrip‐ tors. Each file descriptor in the child refers to the same open file description (see ...


5

If you're doing this in C, you need to do a setsid(2) in your code, along with some fork() and exit() calls. setsid() has this effect: ... creates a new session if the calling process is not a process group leader. The calling process is the leader of the new session, the process group leader of the new process group, and has no controlling ...


5

ps -f normally shows the argument list passed to the last execve() system call the process or any of its ancestors did. When you run a command xxx arg1 arg2 at a shell prompt, your shell usually forks a process searches for a command by the xxx name and executes it as: execve("/path/to/that/xxx", ["xxx", "arg1", "arg2"], @exported_variables) It should be ...


5

Most non-Unix multiprocessing operating systems (OSes) use a "spawn()" call or something similar to generate a new OS process or control flow. Spawn() tends to be a very complex call, with lots of options and lots of overhead. One of Unix's innovations was to provide a much lower overhead way of creating processes - fork(). Unix took care of the many ...


4

Am I then right to think that any pair of processes can be piped to each other? Not really. The pipes need to be set up by the parent process before the child or children are forked. Once the child process is forked, its file descriptors cannot be manipulated "from the outside" (ignoring things like debuggers), the parent (or any other process) can't ...


4

Your question is partly based on bad naming convention. A "thread of control" in kernel-speak is a process in user-speak. So when you read that vfork "the calling thread is suspended" think "process" (or "heavyweight thread" if you like) not "thread" as in "multi-threaded process". So yes, the parent process is suspended. vfork semantics were defined for ...



Only top voted, non community-wiki answers of a minimum length are eligible