lightdm uses ~30 Mb of RAM

Bug #1074279 reported by Jérôme on 2012-11-02
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Light Display Manager
lightdm (Ubuntu)
Michael Terry
Michael Terry

Bug Description

After loging in into the XCFE environment, I open a terminal and perform a top.

If I sort the processes by decreasing resident memory, I see that lightdm requires 32MB of memory, that is more than X !

Since lightdm just sleeps after login in, I think it is wasting memory.

Could it possibly load/unload features dynamically as gdm already did (many small processes which were launched when a feature was required) ?

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: lightdm 1.4.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Fri Nov 2 10:19:19 2012
InstallationDate: Installed on 2012-10-20 (12 days ago)
InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.1)
MarkForUpload: True
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Jérôme (jerome-bouat) wrote :

Yes this is what I get as well. I was shocked to see MATE using 230M with nothing running. It was quite a bit less in Precise.

htop shows lightdm using 31M. Switching to slim and lxdm saved memory, but they are not as useful.

Ubuntu 12.10 Quantal Quetzal
Linux 3.5.0-17-generic i686

Jérôme (jerome-bouat) wrote :

Note that lxdm-binary is the only the 36th memory consumer 2364 kB of physical memory :
j@j-VB:~$ echo -n " " ; ps axl | head -1 && ps axlO-r | awk '{ print NR " " $0 ; }' | head -38 | tail -6
33 0 1000 1076 1009 20 0 74968 2648 poll_s S ? 0:00 xscreensaver -no-splash
34 0 1000 1240 1 20 0 68196 2484 poll_s S ? 0:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
35 0 1000 1109 1 20 0 47492 2476 poll_s S ? 0:00 /usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
36 4 0 801 1 20 0 64568 2364 poll_s Ss ? 0:00 lxdm-binary
37 4 0 1 0 20 0 24452 2264 poll_s Ss ? 0:01 /sbin/init
38 5 104 1380 1 20 0 37688 2176 poll_s Ss ? 0:00 /usr/sbin/ntpd -p /var/run/ -g -u 104:109

Jérôme (jerome-bouat) wrote :

The "slim" login manager uses ~8 MB on amd64.

Decided to use mdm borrowed from mint nadia instead, until lightdm is fixed. Programs that use insane amounts of RAM to their expected usage are prolly broken in other ways too, and can jolly well desist until they behave.

Works OK apart from the (common) mistake a lot of Xsession things make, i.e. using bashisms in a sh, and expecting no errors. Changing #!/bin/sh to #!/bin/bash keeps your ~/.xesssion-errors from getting off to a bad start.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in lightdm (Ubuntu):
status: New → Confirmed

Confirmed on LXDE / Lubuntu. It increased since Ubuntu 12.10, 12.04 was fine

summary: - lightdm uses more physical memory than X
+ lightdm uses ~30 Mb of RAM (more physical memory than X)
Sebastien Bacher (seb128) wrote :

Confirmed, we discussed it at UDS and Michael said he would have a look. Robert feel free to step up if you feel like doing it though ;-)

Changed in lightdm (Ubuntu):
importance: Undecided → High
Changed in lightdm (Ubuntu Raring):
assignee: nobody → Michael Terry (mterry)
summary: - lightdm uses ~30 Mb of RAM (more physical memory than X)
+ lightdm uses ~30 Mb of RAM
Sebastien Bacher (seb128) wrote :

updating the title, comparing to X doesn't real bring any value to it

Jérôme (jerome-bouat) wrote :

Note that gdm requires only 11,4 MB :
j@j-VB:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal
j@j-VB:~$ ps axl | head -1 && ps axl | grep -i gdm | grep -v " \(grep\|/usr/bin/X\) "
4 0 848 1 20 0 202188 3144 poll_s Ssl ? 0:00 gdm
4 0 2852 848 20 0 294540 4408 poll_s Sl ? 0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_1
4 0 2982 2852 20 0 240360 4112 poll_s Sl ? 0:00 gdm-session-worker [pam/gdm-password]

Sebastien Bacher (seb128) wrote :

Robert looked at it, it's due to the memory locking (without locking it drops to 3.7M):

We should maybe turn if off by default...

Michael Terry (mterry) wrote :

Hrm, I feared as much. I'm curious how much security it buys us or if it could be done more selectively.

Michael Terry (mterry) wrote :

Talking to some security folks, apparently we should be locking (i.e. we shouldn't drop the feature). So we just need to do it more precisely.

Also, even with locking, we can hit disk if we hibernate. So we should be clearing the password memory as soon as we're done with it too. (I assume we already don't hold on to those strings...)

Thomas B. (lostis) wrote :

how to disable the memory locking of lightdm ? or is it hard compiled into binary package?

Robert Ancell (robert-ancell) wrote :

You can disable it in lightdm.conf:


Changed in lightdm:
status: New → Triaged
importance: Undecided → Medium
Loïc Minier (lool) wrote :
Download full text (3.7 KiB)

There are two sides doing locking: lightdm itself, and the individual greeters.

Greeters might typically use fancy UI libraries like Gtk+, Qt etc., where it will be hard to clear all password bits; e.g. text input might be passed around multiple layers.

Lightdm will typically pass messages to PAM and get some messages back, not necessarily knowing which ones are passwords.

Now the greeter is usually not running when the desktop is running, so I guess it's not too bad to mlockall() that process since that memory will be freed up for the desktop after a successful login.

Concerning lightdm, we could either scrub all PAM messages after we're done with them, but I'm not sure whether the PAM stack is itself careful about handling not writing passwords to swap and using mlock; another approach would be to implement the lightdm protocol with the greeter in a separate program which would also do PAM, but keep the other common lightdm features separate so that mlocking just the new helper would mlock less memory.

NB1: I was hoping that we were locking a lot of shared read-only pages, but "pmap" on the lightdm process shows that rw pages are mainly from shared libraries:
pmap 1586 | grep rw
0000000000627000 4K rw--- /usr/sbin/lightdm
000000000255a000 284K rw--- [ anon ]
00007f69a8000000 2584K rw--- [ anon ]
00007f69b0000000 132K rw--- [ anon ]
00007f69b6bd7000 4K rw--- /lib/x86_64-linux-gnu/
00007f69b6de3000 4K rw--- /lib/x86_64-linux-gnu/
00007f69b6ffb000 4K rw--- /lib/x86_64-linux-gnu/
00007f69b6ffc000 8K rw--- [ anon ]
00007f69b6fff000 8192K rw--- [ anon ]
00007f69b7800000 8192K rw--- [ anon ]
00007f69b8000000 132K rw--- [ anon ]
00007f69bc369000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bc36b000 8192K rw--- [ anon ]
00007f69bcd6e000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bcf72000 4K rw--- /usr/lib/x86_64-linux-gnu/
00007f69bd17b000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bd3b9000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bd5c1000 4K rw--- /usr/lib/x86_64-linux-gnu/
00007f69bd7d9000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bd7da000 8K rw--- [ anon ]
00007f69bd9f9000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bd9fa000 4K rw--- [ anon ]
00007f69bdc11000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bde15000 4K rw--- /usr/lib/x86_64-linux-gnu/
00007f69be1d1000 8K rw--- /lib/x86_64-linux-gnu/
00007f69be1d3000 20K rw--- [ anon ]
00007f69be3f0000 4K rw--- /lib/x86_64-linux-gnu/
00007f69be3f1000 16K rw--- [ anon ]
00007f69be602000 4K rw--- /lib/x86_64-linux-gnu/
00007f69be820000 4K rw--- /usr/lib/x86_64-linux-gnu/
00007f69bea26000 4K rw--- /usr/lib/x86_64-linux-gnu/
00007f69bed20000 4K rw--- /lib/x86_64-linux-gnu/
00007f69bed21000 4K rw--- [ anon ]


Loïc Minier (lool) wrote :

(just to convince myself that session-child can't see uncleared memory from before the exec())

Loïc Minier (lool) wrote :

Quickly grep-ed shadow (login) and gnome-screensaver, and these don't seem to use mlock at all?!

Michael Terry (mterry) wrote :

I was thinking we'd secure all the buffers we use to communicate with either the greeter, since we don't know ahead of time which messages have passwords. Agreed regarding the greeter. We can probably just use mlockall there.

I am looking at libgcrypt to manage the secure memory pools for us (libgcr is newer and gobject-based, but it pulls in GTK+; libgnome-keyring is semi-deprecated and depends on libgcrypt anyway).

Michael Terry (mterry) on 2013-01-28
Changed in lightdm (Ubuntu Raring):
status: Confirmed → In Progress
Michael Terry (mterry) on 2013-01-31
Changed in lightdm:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

lightdm (1.4.0-0ubuntu3) raring; urgency=low

  [ Michael Terry ]
  * debian/02_disable_tests.patch, debian/rules:
    - Drop patch, disable test suite during build by just overriding
      dh_auto_test. This way we can still manually run tests
  * debian/control, debian/tests:
    - Add dep8 tests to run upstream test suite. The suite only works once
      lightdm is installed into PREFIX. So we must run via dep8.
      Disabled for now until the next upstream release.
  * debian/patches/05_add_xserver_core_option.patch:
    - Modify test X server to also accept -core
  * debian/patches/10_selective_mlock.patch:
    - Backport patch from upstream to not use mlockall for the daemon
      (LP: #1074279)
  * debian/rules:
    - Use ./ when running dh_autoreconf

  [ Matt Fischer ]
  * debian/lightdm.install:
    - Remove duplicate entry /usr/share/man
    - Install apport hook
  * debian/lightdm.postinst:
    - Fix ownership of /var/lib/lightdm
  * debian/lightdm.postrm:
    - Correctly remove /var/lib/lightdm on uninstall
  * debian/
    - Update apport hook
 -- Michael Terry <email address hidden> Thu, 31 Jan 2013 11:05:23 -0500

Changed in lightdm (Ubuntu Raring):
status: In Progress → Fix Released

Confrim. In Ubuntu 13.04 FIXED
brain@brain-Desktop:~$ dpkg -s lightdm | grep Version
Version: 1.4.0-0ubuntu3
brain@brain-Desktop:~$ ps -eo rss,command | grep lightdm
 1724 lightdm
307264 /usr/bin/X :0 -core -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none
 1572 lightdm --session-child 12 21
  952 grep --color=auto lightdm

CSRedRat (csredrat) wrote :

Great work!

Vladimir Rutsky (rutsky) wrote :

Will this fix be ported to 12.10?

I manually installed package from 13.04 (1.4.0-0ubuntu3) to 12.10 and it worked.

Robert Ancell (robert-ancell) wrote :

Fixed in 1.5.0

Changed in lightdm:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers