Orphan process's parent id is not 1 when parent process executed from GNOME Term

11

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

• "Session Init". upstart Cookbook. Ubuntu.
• James Hunt, Stéphane Graber, Dmitrijs Ledkovs, and Steve Langasek (2012-11-12). "Respawning user jobs and PID tracking". Ubuntu Raring upstart user sessions. Ubuntu.
• Nathan Willis (2013-04-17). Upstart for user sessions. LWN.
• systemd. systemd manual pages. freedesktop.org.