First, apologies to those who are not using gnome (KDE users as well as those using more offbeat or cutting edge window managers). I run gnome on all my systems, so I will tell you what I actually know about and leave the rest to someone else.
A "session" is everything you do (and everything that is done for you) after you log in to a linux system. A machine can support multiple sessions, and you can be involved in sessions on more than one machine. These days, sessions are pretty much a windowing system concept. At least hardly anyone ever deals with a unix machine in any other way.
Most people run their linux systems in level 5, so they initially deal with GDM which asks for their user name and password and launches a session for them.
The system wide configuration files for xinit are found in /etc/X11/xinit. User specific configuration files are found in .xinitrc (perhaps also .xserverrc)
GDM itself starts the X server and then throws up the greeter (along with some kind of background). GDM can also do lots of tricky things that I almost never use on my systems. It can interact with remote systems via the XDMCP protocol, while doing this it can offer you a chooser to select one of many remote systems to login to. It can manage multiple X servers on a local machine. It can even be controlled via its own socket protocol. I will not discuss any of this fancy business here. all I am concerned about is the simple behavior where I have one local X server on display :0.
The /etc/gdm directory contains a number of directories, which in turn contain shell scripts to govern various aspects of what GDM does. The script named Default in each of these applies to my single local server scenario.
The real focus of what goes on though is the /etc/gdm/Xsession script (which is a link to /etc/X11/xinit/Xsession). This link provides commonality between session startup from startx/xinit and from gdm. It is of central interest, as it sets up the user session. It is run with the credentials of the user being logged in. It has many options and complexities, one of which could be (but is not) to exec the script /etc/gdm/Xclients.
On my system the Xsession script is apparently invoked as:
Xsession gnome-sessionSo, it simply launches gnome-session. Apparently user specific files like .xsession or .Xclients or .xinitrc are just ignored. The idea of these files used to be that a user could set up a customized session by hacking away on on or the other of them with his favorite text editor.
Apparently this is a change, which has been reported as a bug. See Redhat bugzilla 454657. The fix (circa fc9) is to install a package called xorg-x11-xinit-session, and then dork with a user interface setting, which does sound pretty bogus. A brute force fix would be to hack the /etc/X11/xinit/Xsession file and have it check for the user .Xclients and exec it if it is found. This code is at the end of the Xsession script and to my mind ought to be up in front of the code that now runs gnome-session in every case.
I do the yum install xorg-x11-xinit-session and indeed after this, once I select a user, some menus pop up in the panel at the bottom of the screen (not in the central GDM GUI), and I can select from a "Sessions" menu "User Script" and it now honors the .xsession file for the user. Seems a long way around the tree to me, and I hate using a GUI for settings like this.
Take a look at the directory ~/.config/autostart. This contains a file for each application that is supposed to launch automatically when a user logs in. It may contain two files per application if the option to have gnome save and restore session the configuration has been set.
The files have names like ds9.desktop to start the application fresh, and a name like ds9-2.desktop to save the application info for a restart. It would seem that the second file is used if it exists.
These are pretty self explanatory ascii files that you can hack with the text editor of your choice, but there is also a GUI to manipulate these files called gnome-session-properties
The following information is a little old and crusty, I will update it one of these days .....
Bash starts up as a login shell (to be distinguished from a plain old interactive shell or a non-interactive shell).
It looks for (and executes) startup scripts in the following order (provided that they exist):
First /etc/profile
Then the first of the following that it finds:
Note that if you have more than one of these, only the first will be executed. In my case I have .bash_profile and .bashrc and my .bash_profile invokes my .bashrc (for better or worse).
Bash reads and executes ~/.bashrc if and only if it is not a login shell.
Adventures in Computing / tom@mmto.org