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 $!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?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 can't be anymore useful so it quits?
what happens when a window manager is put to background
process;x11;posix
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  