The session leader process is responsible for asking ConsoleKit to open a new session. In this respect, it is similar to the traditional POSIX user login accounting framework. In the typical case, the session leader is either an immediate descendant of a login manager or the login manager itself. The leader makes a connection to the D-Bus system bus and asks ConsoleKit to open a session. There are two methods available for opening a session: org.freedesktop.ConsoleKit.Manager.OpenSession() and org.freedesktop.ConsoleKit.Manager.OpenSessionWithParameters(). If the operation succeeds, a secret cookie will be returned to the session leader. The session leader should store this secret in the environment as XDG_SESSION_COOKIE so that it may be shared with its child processes. At this point the session will be registered with ConsoleKit and a particular set of information about the session will be stored along with it. ConsoleKit will decide, based on the information associated with the session, what Seat the session will be added to. It will also be determined, based on the same set of information, whether the Session will control the hardware associated with the Seat. In other words, whether the Session will be active for the Seat it is attached to. The exact mechanism for this determination depends on the type of Seat and the capabilities of the host system. The Session will remain open until the Session Leader disconnects from the D-Bus system bus or calls org.freedesktop.ConsoleKit.Manager.CloseSession(). The session will be removed from its Seat, and deregistered. Use of this service will usually follow one of the following patterns: This pattern operates as the Session Leader for a new Session. This pattern needs: To open a new Session. To set properties for the Session. To maintain a connection to the D-Bus system bus. To close the Session at logout. In addition to the requirements for the Text Graphical Login Manager, this pattern is typically used to show information about currently open sessions. It needs: To determine which Seat it is running on. To know if the current seat supports session switching. A list of all sessions on the current Seat. To know which session is active for the current Seat. To know when the session active state changes. To know when sessions are added or removed. Access to the metadata for any open Session. This is generally a daemon process running outside of a user session as a special user. This pattern needs: To know if any user sessions are open. To know if the system is currently being used. This is a special case of System Daemon that provides catalogs and control mechanisms for hardware devices. In addition to the requirements of System Daemon, this pattern needs: To determine what hardware is associated with a Seat. To determine what Session is active and inactive on a particular Seat. To know when the session active state changes. To determine what Session a process belongs to. This is related to the Graphical Login Manager and provides a shortcut to similar functionality. It is usually a tool available in the user session that allows one to quickly switch to another user session. This pattern needs: To determine which session it is running in. To determine which Seat it is running on. To know if the current seat supports session switching. A list of all sessions on the current Seat. Which session is active for the current Seat. To know when the session active state changes. Access to the metadata for any open Session. To know when sessions are added or removed. This is typically a daemon running in a user session that acts on policy only when the session is active. This pattern needs: To determine which session it is running in. To know when the session active state changes. This is typically an application running in a user session that may alter its behavior when the session active state changes. This pattern needs: To determine which session it is running in. To know when the session active state changes.