3

According to what I know, the shell and its child processes are in the same session which have the same (controlling) terminal. I read that they are interactive processes because they have the same terminal associated with. For now, I accept it although does not feel right because the real interaction is between user and the shell.

How about GUI programs (e.g. browser, text editor), window manager and desktop environment? Are they child processes to X11?

correction: each command pipeline in a shell has different PGID. so, child processes of shell do not have same PGID with the shell's.

Improve this question

3 Answers 3

Reset to default
2

The traditional Unix notion of session makes sense for login sessions on a text terminal.

In an X11 session (that's session in the generic sense, not in the specific Unix sense), all processes are normally descendants of a session leader process. This can be the session manager (if there is one), or the window manager, or the launcher (graphical shell) if there is one. There is one process that starts the X11 session and whose death ends the session, but its role varies between desktop environments.

You can observe the process tree with pstree (may not be part of the default installation) or ps axf (Linux only). The X server is not part of the same branch of the tree as the other programs; its role is only to mediate input and output, it is never involved in launching programs. Typically you'll see either xinit or a display manager with two children, one being the X server and the other being the X session leader.

Some of your GUI programs may not be attached to that process tree, if their parent process is dead (for example, because they were started in the background by a wrapper script that then exited).

the real interaction is between user and the shell.

Only if you're actually interacting with the shell. When you're interacting with another program running in a terminal, the shell is not involved. Input and output go directly between the program and the terminal, the shell is just sitting in the background waiting for the program to exit or to be suspended.

Improve this answer
0

edit: I originally misread the question.

X windows is a display server. Client applications communicate with the server using messages. These processes usually don't have an associated terminal as all their input comes from X. If an application requires a terminal, a pseudo-terminal is created and assosiated with the app, for example gnome-shell creates a pty and assosiates bash with it.

original: shell (with job control enabled) creates a process group for every child it creates. x apps communicate with x11, ie are not executed by it.

Improve this answer
3
  • Shell? If I use desktop environment, is there any text shell involvement, e.g. when I execute a program by double clicking? Commented Sep 26, 2015 at 10:02
  • i was reffering to the first part of your question (the shell and it's subprocesses are in the same process group). when you double click an application in i.e nautilus, nautilus executes the application. it's the program's responsibility to communicate with x. i.e. there is no differenciation in the process creation between text and gui. Commented Sep 26, 2015 at 10:15
  • I also edited mine. I am aware of pseudo-terminal when using terminal emulator and X11 is associated with virtual terminal (usually tty7). What I am concerned about is child-parent relationship if any when using GUI shell because X11 is the lowest process in hierarchy when using GUI (hierarchy: DE/Window Manager --> X11 --> driver). I refer to X11 as GUI shell because there is virtual terminal (keyboard, display, mouse) associated with similar to text shell like bash associated with virtual terminal too. Commented Sep 26, 2015 at 12:44
0

Any regular process (including a GUI one) can declare itself a session leader (for example in python via os.setpgrp()) and by default its children spawned after that moment (and all their descendants) will belong to its new session group, not its original one (except, of course, those which themselves become session leaders). The pgid of the new session group is typically (or always, not 100% sure) the pid of the self-proclaimed session leader process.

Here's an actual example:

$ ps -eo pid,ppid,pgid,tty,cmd | egrep "(PPID|konsole|Running)"
  PID  PPID  PGID TT       CMD
 4841  9633  4840 pts/3    grep -E (PPID|konsole|Running)
 7375     1  7374 pts/3    konsole -p name=ROOT -e su -
 9373     1  9373 ?        kdeinit4: kdeinit4 Running...
 9489     1  9373 ?        kdeinit4: konsole [kdeinit] -session 102172181df177000142160830700000083410009_14428560
 9492     1  9373 ?        kdeinit4: konsole [kdeinit] -session 102172181df177000142901958900000018140011_14428560
 9558     1  9373 ?        kdeinit4: konsole [kdeinit] -session 102112051ed1c6000144239124800000016680010_14428560

Most konsole processes listed are started by KDE itself, via kdeinit (pid 9373) and inherit its pgid 9373.

However the konsole pid 7375 (displayed on the same display and controlled by KDE just as the rest of the GUI apps) was started manually from the shell running in one of the other konsole processes. It belongs to pgid 7374 started when this konsole process itself was forked (by its parent pid 7374, now defunct, which became session leader at the time).

Unrelated to the controlling terminal (each of the shells inside those konsole processes has its own tty, for example, but only the manually-started konsole process has one - pty/3, inherited from its ancestor shell, the KDE-started konsoles don't have a tty).

Side note: pid == pgid == 9373 indicates 9373 is a self-proclaimed session leader process as well.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.