what happens when a window manager is put to background

Question

I am trying to understand the situation why .xsession file expects the last process to be in foreground otherwise it is supposed to stop X11 session.

I have a small stand-alone script. when I run this, it immediately quits as 'less' is but in background.

$ ls -l total 4
-rwxr-xr-x 1 user user 17 Feb 28 21:17 a
-rw-r--r-- 1 user user  0 Feb 28 20:22 b 
$ cat a 
less b & 
echo $!

1. I understand 'less' tool primarily interacts in foreground. I do not know how it is implemented, but I guess it realizes that it no more runs in foreground and it can't get input or show some output to user so it is no more useful to run so it quits. Or what is really happening?

2. when you put a 'window manager' in background, why does it quit? Does it quit because it does not run in foreground and cannot get any keyboard/mouse input through X server and it cant be anymore useful so it quits?

Answer 1

Those are actually two completely different phenomena.

less itself doesn't bother to check whether it's in the background (this is typical of programs that interact with terminals). The generic terminal driver in the kernel keeps track of what process¹ is in the foreground. There can only be one foreground process (more precisely one process group). The shell makes a system call (tcsetpgrp) when the fg builtin is used to put a process in the foreground. This system call causes the specified process to become the foreground process.

When a process tries to read from a terminal², if it is not in the foreground, the terminal driver sends the process a SIGTTIN signal. By default, this signal suspends the process (like a SIGSTOP). Similarly, a background process that tries to write to its controlling terminal receives a SIGTTOU. Most shells typically display a message like [1] + suspended (tty output) less myfile when this happens.

For more information about terminals, see the description of the general terminal interface in the POSIX standard. (It's not an easy read. It's a lot more than what most users and even more programmers need to know.)

A window manager doesn't interact with terminals, so the concept of background and foreground processes in terminals doesn't apply to it. What's going on there is that the X server³ terminates when the X session terminates. The script that's calling the window manager tells what to do in the session. If you put the window manager in the background and let the session script exit without waiting for the window manager, this causes the session to end earlier than you expected.

¹ _{What process group, actually (e.g. a pipeline), but we don't need to get into this level of detail here.}
² _{Only to its controlling termina in fact.}
³ _{the back-end part of the GUI, that carries out orders to draw windows, read input and the like from applications}

Answer 2

There is no requirement that the window manager be in the foreground, background, or under any sort of job control at all. You don't even have to run a window manager if you don't want to!

The only thing that's important is that when your .xsession script terminates, that's the end of your session. If .xsession terminates, then the X server itself terminates and whatever processes are still left connected to it are forcibly terminated.

Therefore a .xsession script is normally constructed so that the last thing the script runs is a long-running process of some sort associated with the session. It could be the window manager or it could be a session manager (more typical under a modern fancy desktop environment). This process is either run with exec so that it replaces the shell that is running .xsession or it is run as a foreground process so that the shell will wait for it. Either way, when this process quits, the session ends.

Your example shell script starts less in the background and then immediately quits. It doesn't wait for the background process. It quits regardless of whether or not less does. less might continue to run in the background but whatever started your shell script will not pay any attention to this. A .xsession script that is constructed in the same manner will have the same problem.