How CTRL+C works
The first thing is to understand how CTRL+C works.
When you press CTRL+C, your terminal emulator sends an ETX character (end-of-text / 0x03).
The TTY is configured such that when it receives this character, it sends a SIGINT to the foreground process group of the terminal. This configuration can be viewed by doing stty -a and looking at intr = ^C;.
The POSIX specification says that when INTR is received, it should send a SIGINT to the foreground process group of that terminal.
What is the foreground process group?
So, now the question is, how do you determine what the foreground process group is?
The foreground process group is simply the group of processes which will receive any signals generated by the keyboard (SIGTSTP, SIGINT, etc).
Simplest way to determine the process group ID is to use ps:
ps ax -O tpgid
The second column will be the process group ID.
How do I send a signal to the process group?
Now that we know what the process group ID is, we need to simulate the POSIX behavior of sending a signal to the entire group.
This can be done with kill by putting a - in front of the group ID.
For example, if your process group ID is 1234, you would use:
kill -INT -1234
Simulate CTRL+C using the terminal number.
So the above covers how to simulate CTRL+C as a manual process. But what if you know the TTY number, and you want to simulate CTRL+C for that terminal?
This becomes very easy.
Lets assume $tty is the terminal you want to target (you can get this by running tty | sed 's#^/dev/##' in the terminal).
kill -INT -$(ps h -t $tty -o tpgid | uniq)
This will send a SIGINT to whatever the foreground process group of $tty is.
Tasks do not have a struct cred. They have two struct cred's:
* A task has two security pointers. task->real_cred points to the objective
* context that defines that task's actual details. The objective part of this
* context is used whenever that task is acted upon.
*
* task->cred points to the subjective context that defines the details of how
* that task is going to act upon another object. This may be overridden
* temporarily to point to another security context, but normally points to the
* same context as task->real_cred.
I checked which one /proc shows you, but you can probably guess :-P.
(See fs/proc/, using https://elixir.bootlin.com . The procfs "status" file is defined in fs/proc/base.c.)
Best Answer
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 --useris 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 underlaunchd) 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.)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
systemd. systemd manual pages. freedesktop.org.