lightdm forgets to source /etc/profile and ~/.profile

Bug #794315 reported by Anders Kaseorg on 2011-06-07
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Light Display Manager
lightdm (Debian)
Won't Fix
lightdm (Ubuntu)

Bug Description

Binary package hint: lightdm

/etc/gdm/Xsession had this code:
  # First read /etc/profile and .profile
  test -f /etc/profile && . /etc/profile
  test -f "$HOME/.profile" && . "$HOME/.profile"
  # Second read /etc/xprofile and .xprofile for X specific setup
  test -f /etc/xprofile && . /etc/xprofile
  test -f "$HOME/.xprofile" && . "$HOME/.xprofile"
so that, for example, ~/bin gets added to the path (by the default ~/.profile), and any user-customized environment setup gets run.

After switching from gdm to lightdm, this no longer happens. This is going to be a regression now that lightdm is becoming the default display manager.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lightdm 0.3.7-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.39-3.10-generic 2.6.39
Uname: Linux 2.6.39-3-generic x86_64
NonfreeKernelModules: openafs
Architecture: amd64
Date: Tue Jun 7 19:27:11 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101202)
 PATH=(custom, no user)
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

Anders Kaseorg (anders-kaseorg) wrote :
Scott Moser (smoser) on 2011-06-08
Changed in lightdm (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed

I noticed this with the LightDM drops in the oneiric repos today.

Until this is fixed, you don't automatically get ~/bin added to your path.

seeker5528 (seeker5528) wrote :

Personally I don't expect '~/.profile' and '/etc/profile' to be sourced if I'm not logging in at the command line.

But I do expect '~/.xprofile' to be sourced when logging in to an X session, which currently doesn't happen.

Anders Kaseorg (anders-kaseorg) wrote :

> Personally I don't expect '~/.profile' and '/etc/profile' to be sourced if I'm not logging in at the command line.

Whether or not you expect it, they were sourced under GDM, so this change is a regression.

(If you have setup that should happen only for interactive shells, it probably belongs in ~/.bashrc, not ~/.profile.)

Changed in lightdm:
status: New → Triaged
importance: Undecided → Medium
Changed in lightdm (Ubuntu):
status: Confirmed → Triaged
Rrrrube (rrrrube) wrote :

Can anyone tell me if this issue relates to a problem I'm having. Basically, my .xmodmap file is not being loaded when I log in (I'm running Oneiric with lightDM). I know there's nothing wrong with my xmodmap file because it works perfectly well in other releases, but it's ignored in Oneiric. There's no error or anything. It's just as if the file isn't there.

Is this likely the same underlying problem or should I submit a separate bug? Would appreciate any advice.

Gunnar Hjalmarsson (gunnarhj) wrote :

When using GDM, ~/.Xmodmap is loaded by /etc/gdm/Xsession irrespective of /etc/profile and ~/.profile, so I'd suggest that you file a separate bug.

Rrrrube (rrrrube) wrote :

Will do, thanks.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lightdm - 0.4.0-0ubuntu3

lightdm (0.4.0-0ubuntu3) oneiric; urgency=low

  * debian/control:
    - Make GTK greeters depend on gnome-icon-theme-full (LP: #796793)
  * debian/Xsession:
  * debian/lightdm.conf:
    - Load profile and X resources when running session (LP: #794315)
      (LP: #795083)
 -- Robert Ancell <email address hidden> Fri, 17 Jun 2011 15:26:59 +1000

Changed in lightdm (Ubuntu):
status: Triaged → Fix Released
Yves-Alexis Perez (corsac) wrote :

Note that profile is for login shells, it might not be a good idea to source it from DMs, even though gdm does it. PATH might have to be handled differently.

Changed in lightdm:
status: Triaged → Fix Released
Hwoarang (hwoarang) wrote :


Please re-open this bug. The bug is still present in 1.0.6

This bug was fixed in the /etc/lightdm/Xsession script, which is part of the Debian/Ubuntu packaging, not upstream:

So I think this will need to be dealt with on the Gentoo side, and there’s nothing to reopen from here.

Hwoarang (hwoarang) wrote :

Yeah sorry I posted to the wrong bug

Marty Vona (vona) wrote :

I thought this was catching me (on oneiric) but it turns out that the only variable that wasn't taking effect from my .profile was LD_LIBRARY_PATH. And that seems to be due to bug 47958.

Nikolay Hodyunya (nkhodyunya) wrote :

This bug affects me on 13.04, please re-open.

Sergio Callegari (callegar) wrote :

I have .profile not being sourced on kubuntu 13.10 with lightdm-kde.

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2014-01-28 18:43, Sergio Callegari wrote:
> I have .profile not being sourced on kubuntu 13.10 with lightdm-kde.

Sounds unlikely to me; it should be sourced in /usr/sbin/lightdm-session.

Please note that this bug was closed 2.5 years ago. You may want to ask for help e.g. at

Sergio Callegari (callegar) wrote :

You are right. I thought it was not sourced since I was getting an umask different from that set in .profile. But in fact, I am experiencing another bug, where upstart messes the umask set in .profile. Sorry for the noise.

Changed in lightdm (Debian):
status: Unknown → Won't Fix
jtniehof (jtniehof) wrote :

Note that the profile is sourced at the top of /usr/sbin/lightdm-session, and the bottom of lightdm-session runs everything in /etc/X11/Xsession.d. The final file is 99x11-common_start, which is exec $STARTUP. Thus this never returns to the exec in lightdm-session. Since 99upstart (from upstart package, so pretty much always present) smashes STARTUP to "init --user", the X session is actually started by upstart--which does not pass through the environment so carefully established in lightdm-session (see "Job environment" in init(5)).

Consensus on askubuntu ( ) seems to be "a graphical login shell is not a login shell," which basically requires the treatment of every new terminal window as a new "login shell" if there's to be a rational environment in there. If this was ever considered a bug, it appears to have reverted now.

I've been digging through this specifically on Xubuntu 14.04, but again, the players involved seem to be pretty deep in the stack.

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.