The new gdm doesn't give an option to run /etc/X11/Xsession

Bug #398300 reported by Erik de Castro Lopo on 2009-07-11
This bug affects 38 people
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Martin Pitt
Ubuntu Desktop Bugs

Bug Description


  * create an ~/.xsession script:

    echo "exec xterm" > ~/.xsession
    chmod 755 ~/.xsession

 * Log out, check which session you have selected (presumably GNOME), and check that you get GNOME when logging back in
 * Log out, switch the session to ~/.xsession, and check that you get a session with a single xterm window. (Type "exit" to close it)
 * Remove ~/.xsession, log out, back in, and check that you get a standard GNOME session even with the ~/.xsession session selected.

 * adds the .desktop file (by running "default" instead of /etc/X11/Xsession, we avoid running Xsession.d/* twice; /etc/gdm/Xsession already takes care of this)
 * adds some missing exports to /etc/gdm/Xsession, as a prerequisite for the new session to work (see bug comments for details).

REGRESSION POTENTIAL: There might be flaws or custom configurations where ~/.xsession is run even with a different session selected in gdm. Having ~/.xsession is a rather uncommon situation in the first place, though; this scenario should be tested during verification. (Martin Pitt already did that on his machine)

Binary package hint: gdm

Gdm 2.26.1-0ubuntu5 in Ubuntu Karmic ignores .xsession file and doesn't start my prefered window manager.

Sebastien Bacher (seb128) wrote :

Thank you for your bug report, what session do you select?

Changed in gdm (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
importance: Undecided → Low
status: New → Incomplete

Sebastien Bacher wrote:

> Thank you for your bug report, what session do you select?

I left it as GNOME.

However, I've been running Ubuntu since breezy and have always set
the window manager in the $HOME/.xession file. Previous versions of
gdm would allow whatever session was set up in gdm to be overrridden
by the contents of $HOME/.xession. At various times I have run
fluxbox, openbox, enlightenment 17 and xmonad in this way.

The $HOME/.xession file also allows the running of tools like xmodmap,
xrdb and xset. This no longer works with the Karmic version of gdm.

Erik de Castro Lopo

the GNOME session is GNOME as indicated, .xsession is used when you select the user session

Sebastien Bacher wrote:

> the GNOME session is GNOME as indicated, .xsession is used when you
> select the user session

So why doesn't the new gdm offer a user session option?

Erik de Castro Lopo

> So why doesn't the new gdm offer a user session option?

the option should be there so that would be a bug

Changed in gdm (Ubuntu):
status: Incomplete → New
Jonathan Thiessen (jjthiessen) wrote :

Please take a look at my proposed fix in duplicate bug report #399516.

summary: - gdm ignores .xsession file
+ New gdm doesn't give an option to use .xsesison
summary: - New gdm doesn't give an option to use .xsesison
+ New gdm doesn't give an option to use .xsession
summary: - New gdm doesn't give an option to use .xsession
+ The new gdm doesn't give an option to use .xsession
Changed in gdm (Ubuntu):
status: New → Triaged
Changed in gdm:
status: Unknown → New
Jordan Reese (jordanmreese) wrote :

GDM calls this a non issue, and says that it's up to the distributions to include a specially crafted .desktop file in /usr/share/Xsessions that runs the system xsession script.

Traumflug (mah-jump-ing) wrote :

They are kidding, aren't they? .xession or .xsessionrc files are in existence and well documented for some 20 years and now they want distros to craft their own flavour? Sligthly different for each distro?

Jonathan Thiessen (jjthiessen) wrote :

Traumflug: No. The .desktop file is what may vary from system to system. This means that the name of the option in your display manager may be different, however, the basic behaviour should be invariant. That is, .xsession and .xinitrc should work the same as they always have, it's just that the display manager will now be xsession script agnostic (no special case handling).

I must say that I agree with the GDM people on this one. The .desktop approach is (at least somewhat?) standard. This could make multiple display managers on the same system reflect the same system policy (eg not allowing user xsession scripts if the appropriate file does not exist)(supposing nobody else offers it as a built-in option), and give a more consistent view (the options would have the same names and descriptions across different display managers).

Edward Z. Yang (ezyang) wrote :

I've tried the suggested fix in /usr/share/xsession but haven't been able to get it to work. Can someone else verify?

Edward Z. Yang (ezyang) wrote :

I've got it working: the file should be:

[Desktop Entry]
Comment=This runs ~/.xsession

Mikael B (mikaelbje) wrote :

Edward's solution works great

Damien Robert (robertdamien) wrote :

There is still a small problem with this solution:
/etc/gdm/Xsession will source the files in /etc/X11/Xsession.d/ and then the file 99x11-common_start will launch
/etc/X11/Xsession, which will source the files in /etc/X11/Xsession.d/ again. In particular there will be two ssh-agents and two dbus session launched, which is not too good.

In the .desktop file:
should work, but it does not because of bug #465349.
(and it works for me since i modified /etc/gdm/Xsession to source /etc/X11/Xsession)

Tore Anderson (toreanderson) wrote :

I'm also bitten by this bug - after an upgrade to Karmic the ~/.xsession script isn't read anymore and my htpc user is auto-logged in straight into GNOME.

Tried to make files in /usr/share/xsessions that launched /etc/gdm/Xsession (or "/etc/gdm/Xsession custom") and also updated my ~/.dmrc to refer to the new session, but it still didn't work and I was logged straight into GNOME (and for some reason ~/.dmrc was reset to the "default" session).

My (admittedly dirty) solution was:

cp ~/.xsession /etc/gdm/Xsession
chmod a+x /etc/gdm/Xsession


Todd Deshane (deshantm) wrote :


Add a file named "Xsessions.desktop" to /usr/share/Xsessions with the contents:

[Desktop Entry]
Comment=This runs ~/.xsession

Martin Stjernholm (msub) wrote :

The .desktop file can also be put into /etc/X11/sessions/ (you probably have to create the directory first). That's a bit better than changing in /usr/share. C.f.

Mark Wilkinson (mhw) wrote :

I've got an alternative explanation for what's going wrong here. The default GNOME session runs gnome-session and this in turn runs /etc/gdm/Xsession as mentioned in comment #14. As pointed out there, /etc/gdm/Xsession runs through the session scripts in /etc/X11/Xsession.d. This includes 50x11-common_determine-startup which should cause ~/.xsession to be picked up. What's going wrong is that a set of environment variables that are normally set by /etc/X11/Xsession are not set by /etc/gdm/Xsession, including things like USERXSESSION. So when the scripts run they don't behave as designed.

A simple kludge to get things working is to observe that /etc/gdm/Xsession sources /etc/xprofile and ~/.xprofile very early on, and we can use one of these files to set the environment up correctly for the Xsession.d scripts. Stick the attached script into /etc/xprofile (or ~/.xprofile) and see if that gets .xsession working again. It works for my dot files that depend on .xsessionrc getting sourced.

I'm not sure what a more correct fix would look like as I haven't delved into which files are sourced from Debian/Ubuntu sources and which are from upstream (and hence less favourable for changes).

Tv (tv42) wrote :

Creating ~/.xprofile as per comment #18 did not make the "GNOME" session execute the window manager I have in ~/.xsession, as it used to do before this bug happened.

Andy (andy-xillean) wrote :

Creating a custom logon session at the login prompt does not help my situation. Before when a specific user logged in the .xsession file would run and startup firefox. That specific user was only able to run firefox. No windowmanager or anything else. When they close Firefox it would end the session
the user's .xsession file was very simple.
exec firefox

Creating a session desktop entry at the login prompt allows the user to bypass the ability to restrict the user to a specific application. All they have to do is change the session type on the login window to gnome or whatever and login to get a full desktop bypassing their .xsession file. This is shortsighted IMO on the part of the Gnome devs. It was simple now they have made this complicated if not impossible to do now.

Is there a way to run just one application when a specific user logs in the log them out when they close that app?

Benjamin Mako Hill (mako) wrote :

Comment #16 has a clear answer to this bug. Upstream seems unwilling or uninterested in fixing this as they believe this deserves to be solved by distributions. That means Ubuntu needs to address this. Luckily, all we need to ship a four line desktop. Let's do this and close this bug.

Changed in gdm (Ubuntu Lucid):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Canonical Desktop Team (canonical-desktop-team)
Martin Pitt (pitti) on 2010-03-16
Changed in gdm (Ubuntu Lucid):
assignee: Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)
Martin Pitt (pitti) on 2010-04-26
summary: - The new gdm doesn't give an option to use .xsession
+ The new gdm doesn't give an option to run /etc/X11/Xsession
Martin Pitt (pitti) on 2010-04-28
Changed in gdm (Ubuntu Lucid):
status: Triaged → In Progress
milestone: none → lucid-updates
tags: added: regression-release
Martin Pitt (pitti) wrote :

Fixes committed to bzr (see bug description update), and uploaded to lucid-proposed. Awaiting SRU team review/approval. Please note that this comes bundled with bug 518810 and a new upstream microrelease.

description: updated
Changed in gdm (Ubuntu Lucid):
status: In Progress → Fix Committed

Accepted into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gdm - 2.30.2-0ubuntu1

gdm (2.30.2-0ubuntu1) lucid-proposed; urgency=low

  * New upstream bug fix release:
    - Accessibility is now enabled by default for the GDM login screen.
    - When the face browser is disabled, the PAM conversation is started
      immediately, so users do not need to click a button to start entering
      the username and password. (GNOME #591082)
    - Add label-for and labelled-by a11y relations to the entry field in the
      login GUI. This makes the login GUI more accessible when using AT programs.
      (GNOME #613434).
    - Fixed bugs that were causing XDMCP to not show the greeter again after
      logout. (GNOME #606724).
    - The default XDMCP PingIntervalSeconds was increased from 15 to
      60 seconds.
    - The WINDOWPATH environment variable is now set for the user session.
      (GNOME #609272)
    - Ensure Init script is called when using Automatic Login. (GNOME #614488)
    - Fix race condition with Timed Login. (GNOME #614062)
    - Drop xhost localuser:gdm and localuser:root when the user session starts.
      (GNOME #605350)
    - Removed the icon monitor from the GDM login GUI since it was not functional
      and was causing problems with automounting user's $HOME directories.
      (GNOME #609321, LP: #518810)
    - Do not mark "%x" for translation. (GNOME #613306)
    - Remove duplicated strings for translation. (GNOME #609179)
    - Minor doc corrections.
    - Translation updates.
  * 04_fix_external_program_directories.patch, 99_autoreconf.patch: Refresh
    for new upstream version.
  * Add 34_disable_a11y_default.patch: Revert upstream change between 2.30.0
    and 2.30.1 to enable a11y by default. This wasn't tested and isn't
    appropriate for an SRU.
  * 06_run_xsession.d.patch: Export $USERXSESSION, $USERXSESSIONRC, and
    $ALTUSERXSESSION, so that running the "custom"/"default" sessions actually
    works. Without those, /etc/X11/Xsession.d/50x11-common_determine-startup
    decides to run the system default session even if we have the
    "allow-user-xsession" option. This is a prerequisite for fixing LP#398300.
    Also update the patch tag header to comply to DEP-3.
  * Add debian/xsession.desktop: Add a new session type "~/.xsession" which
    will run ~/.xsession (Exec=default will be interpreted by the
    20x11-common_process-args and 50x11-common_determine-startup Xsession.d
    scripts). If the admin sets "allow-user-xsession" to False, this will
    launch the system default session instead. (LP: #398300)
 -- Martin Pitt <email address hidden> Wed, 28 Apr 2010 14:41:12 +0200

Changed in gdm (Ubuntu Lucid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Copied lucid-proposed to maverick.

Changed in gdm (Ubuntu):
status: Fix Committed → Fix Released
Changed in gdm (Ubuntu Lucid):
status: Fix Released → Fix Committed
Anders Kaseorg (andersk) wrote :

Works for me with gdm 2.30.2-0ubuntu1 on Maverick.

Martin Pitt (pitti) wrote :

Thanks Anders. It works here as well (on lucid), and since maverick has the binary identical package to lucid-proposed I count your's as verification.

tags: added: verification-done
removed: verification-needed
Joel Ebel (jbebel) wrote :

The package in lucid-proposed breaks users who set disable_user_list to true. The result is that you still get a Log In button (which the changelog indicates shouldn't happen anymore) but when you click it, GDM crashes. Reverting to the version in Lucid main resolved the issue.

Joel Ebel (jbebel) wrote :

See bug 579044 for details of the regression.

tags: added: verification-failed
Martin Pitt (pitti) wrote :

In bug 475090 it was mentioned that we also need to read ~/.xsessionrc.

Changed in gdm (Ubuntu Lucid):
assignee: Martin Pitt (pitti) → Sebastien Bacher (seb128)
assignee: Sebastien Bacher (seb128) → nobody
Sam Vilain (sam-vilain) wrote :

This new package didn't seem to work for me after a Lucid re-install - I still needed to put the .desktop file in /usr/share/xsessions - any debugging tips? I also use ecryptfs ~, if that is important.

Jeremy Nickurak (nickurak) wrote :

Likewise. I still need to create a /usr/share/xsessions/xsession.desktop as below. This is not in the lucid-updates fix yet, and until it does, this bug isn't really resolved.

[Desktop Entry]
Comment=Legacy Xsession

Changed in gdm:
importance: Unknown → Medium
status: New → Unknown
anarcat (anarcat) on 2010-09-20
Changed in gdm (Ubuntu Lucid):
status: Fix Committed → Incomplete
anarcat (anarcat) wrote :

Marking this incomplete as the latest gdm version in Lucid 2.30.0-ubuntu5 doesn't have such a menu. The source I downloaded ( is also not working. A forum post suggested the following desktop entry:

[Desktop Entry]
Comment=Custom Xsession

Anders Kaseorg (andersk) wrote :

anarcat: “Incomplete” means that the bug report is missing information, not that the bug is not yet fixed. Marking “Confirmed” instead.

Changed in gdm (Ubuntu Lucid):
status: Incomplete → Confirmed
Jonathan Michalon (johndescs) wrote :

No activity on this for a while… but issue still exists. What a shame. I fixed Xsession problem manualy adding the .desktop, and continuously hit the login button of disable_user_list. I came across this just today another time on a newly upgraded Lucid.
Furthermore -proposed package don't seems to exist anymore. What should I do to get ride of the extra-click and have custom .xsession cleany done without hacking in /u/s/xsesssions ?

Martin Pitt (pitti) wrote :

Jonathan, the bug was fixed in Ubuntu 10.10. It's not suitable for a stable release update to 10.04 LTS.

Jonathan Michalon (johndescs) wrote :

Oh. OK. Reading previous comments with -propsed etc. I just thought it went forgotten in the depth of forgetfulness.
Would it be possible to set a "won't fix" status to avoid others thinking the same as I did? As is with "confirmed" one may think that it could evolve…

Martin Pitt (pitti) wrote :

Oh, sure. Sorry about that oversight.

Changed in gdm (Ubuntu Karmic):
status: Triaged → Won't Fix
Changed in gdm (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in gdm (Ubuntu):
milestone: lucid-updates → none
Changed in gdm (Ubuntu Lucid):
milestone: lucid-updates → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.