ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One of the fundamental design-points of Linux or Unix is that many things are done by "spawning child processes" to do things, then waiting for them to finish and examining the return-code they provide. For this reason, when a process dies, it enters a "zombie" state that specifically exists so that the parent-process can "reap" the now-dead child and, in so doing, collect its status information.
"But what if the parent dies first?"
Generally, but not always, the death of a parent causes the death of all of its direct or indirect children. But in any case, when any process dies, some "parent process" must "reap" it.
If there is no "true" parent-process available, "process #1: init" gets to serve as the Grim Reaper, among its various other duties.
"init" is a very special process: it is created by the system during startup, and it never dies. (It is not allowed to die... a "kernel panic" will occur if it ever does.)
when a process is created it's typically from a user's shell, the shell is the session leader.
and the parent. when you logout the shell all the kids die too.
they get a signal from the parent.
sometimes you want a process to be independent of the parent, like a daemon, so it doesn't
die when you log out.
so typically if you want this behaviour the program calls fork
followed by setsid
becoming a session leader and getting the PPID of 1 the 'init' process
which is the ultimate parent of all.
e.g. gvim does this.
Just to clarify - jan61's response is probably closest to what you were actually looking for:
Quote:
You can yourself create such processes using "nohup program &"
The reason to use "nohup" is 1) you want to spawn a subprocess, but 2) you want to disassociate it from your login (in other words, you want the new process to continue, even after you log out).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.