Re^2: Keep a "system" process running if script is prematurely exited?

I'm not sure what it does

setsid(2) creates a new session and connection to the controlling terminal is lost. The calling process becomes the new session and process group leader. This is commonly used to disconnect from a terminal when writing a daemon.

I doubt it is relevant here. The editor being launched is an X-Windows application which does not use STDIN/OUT/SHAKEITALLABOUT. Is it Friday yet?

Comment on Re^2: Keep a "system" process running if script is prematurely exited?

Replies are listed 'Best First'.
Re^3: Keep a "system" process running if script is prematurely exited? by ikegami (Patriarch) on Jun 17, 2010 at 14:38 UTC
Copying the docs isn't very useful. I still have no idea what "disconnecting from a terminal" means.	[reply]
Re^4: Keep a "system" process running if script is prematurely exited? by cdarke (Prior) on Jun 17, 2010 at 16:42 UTC
All the processes started from the same process share the same session and the same terminal. This is true when started with '&', run on the command-line, or fork/exec within a program. When setsid() ("set session id") is called we create a new session which does not have a terminal. By default, the process which calls setsid() is moved to the new session (setsid() can take a PID as a parameter). The process is now the only process in the new session, unless it starts new processes itself. It does not have a terminal and ps -ef will show ? against its TTY column. This is the usual way that a daemon disconnects from a terminal since it does not want signals from the keyboard. (Not copied from doc)	[reply]
Re^5: Keep a "system" process running if script is prematurely exited? by ikegami (Patriarch) on Jun 17, 2010 at 19:52 UTC
So one calls setsid to avoid getting signals from the keyboard. But that can't be all; the OP's question doesn't involve sending signals from the keyboard. Update: http://en.wikipedia.org/wiki/Process_group answers the question.	[reply]