X session manager

In the X Window System, an X session manager is a session management program, a program that can save and restore the current state of a set of running applications.

Overview

From the point of view of an X session manager, a session is a “state of the desktop” at a given time: a set of windows with their current content. More precisely, a session is the set of clients managing these windows or related to them and the information that allows these applications to restore the condition of these windows if required.

The most recognizable effect of using a session manager is the possibility of logging out from an interactive session and then finding exactly the same windows in the same state when logging in again. For this to work, the session manager program stores the names of applications that are running at logout and starts them again at login. Moreover, for the state of the applications to be restored as well (which is needed to restore the content of windows), the applications must be able to save their state of execution upon request from the session manager and load it back when started again. In general, a session can be saved or loaded at any time, even if the user is not logging in or out. It is also possible to save a number of different sessions and loading one of them at user's choice. Sessions can also be specified by providing the list of applications that compose the session. As a result, the user has the possibility of saving a set of different sessions, either by storing the state of execution of the currently running applications or by explicitly listing the applications that compose a session. This way, the user can later decide to load a given session.

In order for a session to include the state of an application, the application must be able to store and load its current state when appropriate. A protocol named "X Session Management Protocol" (XSMP) specifies how applications and session managers interact. Of particular importance is that the window manager is able to communicate with the session manager, as the window manager is responsible for the placement of windows and the existence of icons. Applications that cannot store their state can be included in a session, but they do not preserve their state across sessions. The X Window System include a default session manager called xsm. Other session managers have been developed for specific desktop systems: for example, ksmserver is the default session manager of KDE.

The Protocol

The XSMP is a subprotocol of the Inter-Client Exchange Protocol. The client starts the protocol by connecting to the session manager. How the session manager is located on the network is system-dependent: in a POSIX system, the environment contains a variable SESSION_MANAGER. Therefore, when a client is launched, its environment must contain this variable with an appropriate value.

Identifiers

The protocol takes into account two facts:

# in order for a session to be restarted properly, not only the applications running in it must be restarted, but they must also be restarted in such a way they restore their previous state;
# the same application may be running more than once in the same or different session.

Different instances of the same application may be active at the same time in the same or in different sessions, and these instances most likely have different states of execution. For example, the user may have launched a text editor on file /etc/passwd, then on file letter.txt in the same session, and then on file todo.txt in another session.

In order for the sessions to be restored properly, different instances of the same application must be recognized as different by the session manager. For this reason, the session manager chooses a unique identifier for each instance of each application. This way, the session manager is able to distinguish between the text editor that is running on /etc/passwd and the text editor running on todo.txt, even if they are two instances of the same program.

The identifiers must be unique. In particular, they must be unique to all sessions managed by the session manager: the identifier of the text editor running on /etc/passwd is different not only from the same text editor running on letter.txt but also different from the text editor running on todo.txt in another session. The identifier of a client remains the same even if the session is shut down and restarted.

The main parts of the protocol

The main parts of the protocol of session management are:

# the session manager chooses a unique identifier for every client
# the session manager requests clients to save their state
# a client specifies how it has to be started again in order for the state to be restored (e.g., the command line to be used to start the process)

The last point is possible because the session manager maintains a set of properties for every client (in the X Window System terminology, a property is simply a container for data). These pieces of information can be modified by the client at any time. One of these properties is named RestartCommand, and contains the information on how the client has to be started again.

When the session manager requests a client to save its state, the application proceeds as follows:

# it saves its state in such a way the states of two different instances can be distinguished; this can be obtained for example by saving the state in a file whose name contains its identifier
# it stores the specification of how it has to be started again in the RestartCommand property; this property must contain the client identifier because:
## the application must retain its identifier when started again
## the identifier is needed to restore the state (for example, it is needed to find the file where its state is stored)

The session manager maintains other properties beside RestartCommand. For example, a property specifies how to run the application if the session is destroyed.

Local and global state

When asking a client to save its state, the window manager can specify whether the local or global state (or both) has to be saved. The difference is whether the result of the save should be visible to the other applications or not.

In the case of the text editor, saving the global state means saving the file normally, so that other applications can use the new version of the file. Saving the local state means that a local copy of the file has to be saved, so that other applications cannot see the file has if it has not been saved.

An example

The following are the main steps in the interaction of a session manager with the hypothetical text editor xyx when this application is started for the first time in a session, then the user logs out and then in again:

# the application connects to the session manger via the Inter-Client Exchange Protocol
# the application tells the session manager that this is the first time it is started, and therefore it has no previous identifier (and, therefore, no previous state)
# the session manager replies by sending the client its unique identifier, say 4324;
# the session manager immediately asks the client to save its local state (only because the client has been started for the first time)
# the client stores the command line xyz -sid 4324 as the property RestartCommand in the session manager (this is also system-dependent: in a POSIX system, this property actually contains the argv array)
# the client stores its state locally; for example, it may store the name of the edited file and all other information (such as the current line) in the local file .temp-4324
# when the user logs out, the session manager sends a message to all client notifying that they have to save their state
# the client 4324 complies again
# when all clients have communicated the session manager that their state is saved, the session manager shuts down the session

When the client is told to save its state, it may have the possibility of having a limited interaction with the user or not (for example, to ask the user if the edited file is to be saved). Anyway, the state is saved, it tells the session manager by sending an appropriate message).

When the session is started again, the following take place:

# the session manager restart the client 4324 by executing what is stored in the property RestartCommand associated with the client 4324
# the application is therefore started as xyz -sid 4324; this way, the application knows its identifier
# the application retrieves the state information from the file .temp-4324
# the application connects to the session manager specifying the identifier 4324, so that the session manager knows that this is not a new client but an old one restarting

Client-managing sessions

According to the XSMP protocol, a session manager is an arbitrary program that runs and controls the state of other applications. As a result, a client can itself be a session manager of other clients. For example, a mail client can start a text editor for the sake of writing an email, and behave as a session manager with respect of the editor. This way, if the mail client is closed and then restarted again, it can restore the state of the text editor.

See also

* X Window System protocols and architecture
* X window manager

External links

* [ftp://ftp.x.org/pub/X11R7.0/doc/PDF/xsmp.pdf The X Session Management Protocol]
* [http://www.die.net/doc/linux/man/man1/xsm.1.html xsm manual page]
* [http://people.fruitsalad.org/phil/kde/userguide-tng/ksmserver.html ksmserver] , the KDE session manager
* [http://www.collaborium.org/onsite/jos2000/related/guides/gnome/gccsession.html gnome-session] , the GNOME session manager
* [http://rox.sourceforge.net/desktop/ROX-Session ROX-Session] , the ROX Desktop session manager