Hot answers tagged fork
33
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 ...
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 ...
16
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 ...
15
What's the difference between running a program as a daemon and forking it into background with '&'?
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.
14
What's the difference between running a program as a daemon and forking it into background with '&'?
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 ...
12
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 ...
11
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 ...
9
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 */
...
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 ...
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
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 ...
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
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 ...
5
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 )
5
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 ...
5
What's the difference between running a program as a daemon and forking it into background with '&'?
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.
...
3
What's the difference between running a program as a daemon and forking it into background with '&'?
The difference between running a program/process as a daemon and forking it to the background using the ampersand is basically related to ownership.
Most often, the parent process of a daemon is the init process (the very first process to be started on a Unix system), the daemon being a child of that process means that it is not under your direct control as ...
3
How a fork bomb works: in C (or C-like) code, a function named fork() gets called. This causes linux or Unix or Unix-a-likes to create an entirely new process. This process has an address space, a process ID, a signal mask, open file descriptors, all manner of things that take up space in the OS kernel's somewhat limited memory. The newly created process ...
3
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 ...
3
I know that the kernel has a parameter NPROC which tells it the maximum amount of processes which can be run at the same time. I imagine if you're already at the maximum and try creating another one, you will be denied from the kernel and return -1 to your parent.
On another note, the kernel also has a limit of processes per user stored in the MAXUPRC ...
3
fork starts a process in the background. When the foreground process (the one that calls fork) terminates, the calling shell is notified, and it shows a new prompt. The shell is the parent of the original, foreground process; it's not the parent of either forked process.
The order in which the original process and the forked process execute is not fixed, ...
3
In adition to the cjm's answer, the Single Unix Specification defines a function named vfork(). That function works like fork, except that the forked process has undefined behavior if it does anything other than try calling an exec familly function, or calling _exit().
Thus pretty much the only use with defined behavior is:
pid_t ret = vfork();
if(ret == ...
3
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 ...
3
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 ...
2
There's no native bash (or, to my knowledge, any other typical *nix shell) way of doing this. There's a lot of ways to spawn forked processes that do something else asynchronously, but I don't think there's anything that follows the exact semantics of the fork() system call.
The typical approach would be to have your top-level script spawn off helpers that ...
2
The forked process needs act as if it was an exact image of the parent, so without COW it would indeed own 10 frames initially.
But it can't initially own no memory of its own at all - at least one non-shared frame is necessary: fork doesn't return the same value in the parent and the child, so the page where that return value is stored cannot be shared.
...
2
Typically the parent process waits until the child process ends by calling waitpid. The parent process gets the PID of the process from fork.
This means the child never signals the parent process in any way that it exited or what happened. This is done by the system and not the child process.
If you are talking about the output of the program, the parent ...
2
ls will output what it has to output on its standard output. To do that, it calls the write system call, something like:
write(1, "file1 file2...\n", 16)
(or more likely it calls libc functions like printf or fwrite that eventually do the write() system call)
It assumes that the file descriptor 1 (stdout by convention) was already opened and points to ...
2
The shell of the pipeline is the common parent which sets up a communication channel between the several members of the pipeline.
Any process can be piped to any other. The only processes that can usefully be piped together are "filters" that read from stdin and write to stdout.
For example, if you issue the command
$ tail -f /etc/motd | tail -f | cat ...
2
That sentence isn't very clear. First, parent should be ancestor, as the process setting up the pipe can be a parent, or a grandparent, or a grand-grand-…-grandparent, or one of the communicating processes. Second, the sentence doesn't mean “if you want a pipe, there must exist a common ancestor process”, but “if you want a pipe, a common ancestor process ...
Only top voted, non community-wiki answers of a minimum length are eligible
