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 can't be anymore useful so it quits?


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

  • Thanks for your answer. I have definitely all answers a few times. 1. I understand that X session ends when the .xsession script finishes and having some process in the foreground prevents the script to complete. 2. In my sample code, I understand that less would have received SIGTTIN. why does less quit when it put into background? 3. can you refer to some material to learn about foreground and background concepts related to X? 4. can you refer to some essential material to learn on how X passes on input to X client apps/window manager? – rag Mar 1 '13 at 20:52
  • @rag 2. less doesn't quit when you put it in the background. It quits if you close the terminal. 3. X doesn't have foreground/background in that sense. 4. Look up X events. – Gilles 'SO- stop being evil' Mar 4 '13 at 1:35
  • thanks again. but less seems to quit with that particular example i have. i cannot find a less process anymore. – rag Mar 4 '13 at 8:10

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.

  • thanks for your answer. i still have a few doubts. 1. are you saying the X server runs in the foreground to get user input and pass on to window manager so that wm may run in background? 2. in my example, do you hint that script itself is a bash process that starts a child 'less' process and when it exits, it sends some signal causing 'less' to terminate? i am confused with this bit. can you please explain why when a parent bash script exits it causes child background processes to terminate? – rag Feb 28 '13 at 23:33
  • 1
    1. The X server does not run in the "foreground" or "background" as those terms are defined with reference to controlling terminals and job control (See Gilles' answer for details on that). – Celada Mar 1 '13 at 0:25
  • 2. the shell script (which is not a bash script here but a general shell script) does not send any signal to less to cause it to terminate. After the shell script exists, less loses its parent, is inherited by init, and is on its own. It can continue if it wants to, or not. In this particular case, less is an interactive process and it cannot interact with the controlling terminal if it is not the foreground process, so it won't accomplish much. However in the case of .xsession and a window manager, there is no controlling terminal and no interactive process. Any process can run. – Celada Mar 1 '13 at 0:30
  • Re: "explain why when a parent bash script exits it causes child background processes to terminate". It does not have this effect at all. – Celada Mar 1 '13 at 0:31
  • i really appreciate for answering all those questions. – rag Mar 1 '13 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.