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 typically never receives the output of the child process unless it provided fds. This also means that the child process prints the output and not the parent process. The parent process just receives information about the state of the process (for more information see the macros in the waitpid manpage)
I already answered a similar question a few months ago. So see that first for technical details. Here, I shall just show you how your situation is covered by that answer.
As I explained, I and other writers of various dæmon supervision utilities take advantage of how Linux now works, and what you are seeing is that very thing in action, almost exactly as I laid it out.
The only missing piece of information is that init --user is your session instance of upstart. It is started up when you first log in to a session, and stopped when you log out. It's there for you to have per-session jobs (similar, but not identical, to MacOS 10's user agents under launchd) of your own.
A couple of years ago, the Ubuntu people went about converting graphical desktop systems to employ upstart per-session jobs. Your GNOME Terminal is being started as a per-session job, and any orphaned children are inherited by the nearest sub-reaper, which is of course your per-session instance of upstart.
The systemd people have been, in recent months, working on the exact same thing, setting up GNOME Terminal to run individual tabs as separate systemd services, from one's per-user instance of systemd. (You can tell that your question is about upstart, not systemd, because on a systemd system the sub-reaper process would be systemd --user.)
How can I execute a new process from GNOME Terminal so that the child process's parent PID becomes 1 and not the PID of the ubuntu session init process?
This is intentionally hard. Service managers want to keep track of orphaned child processes. They want not to lose them to process #1. So the quick précis is: Stop trying to do that.
If you are asking solely because you think that your process ought to have a parent process ID of 1, then wean yourself off this idea.
If you erroneously think that this is an aspect of being a dæmon, then note that dæmons having parent process IDs of 1 has not been guaranteed (and on some Unices, not true across the whole system) since the advent of things like IBM's System Resource Controller and Bernstein's daemontools in the 1990s. In any case, one doesn't get to be a dæmon by double-forking within a login session. That's a long-since known to be half-baked idea.
If you erroneously think that this is a truism for orphaned child processes, then read my previous answer again. The absolutism that orphaned children are re-parented to process #1 is wrong, and has been wrong for over three years, at the time of writing this.
If you have a child process that for some bizarre reason truly needs this, then find out what that bizarre reason is and get it fixed. It's probably a bug, or someone making invalid design assumptions. Whatever the reason, the world of dæmon management changed in the 1990s, and Linux also changed some several years ago. It is time to catch up.
Further reading
Best Answer
Since we’re discussing Linux specifically (at least, I take it that’s what you want since you used the linux tag), the
forkandexecvemanpages are the appropriate references; they list all the attributes which aren’t preserved. Most of this behaviour is specified by POSIX, but there are some Linux specificities.The man pages don’t list attributes which are preserved, focusing instead on those which aren’t:
etc.
I won’t try to answer your question by listing all the attributes which are preserved. However I will point out one key property which is preserved, and which you haven’t listed: ignored and default signals are preserved across
execve. This means that a parent can ignore a signal (at least, signals that can be ignored) and that behaviour will be propagated to any children. This is what allowsnohupto work.You can find a complete list of process attributes, with an explanation of what happens to them on
exec()orfork(), in section 28.4 of The Linux Programming Interface.