Bug 473547 - console-kit-daemon huge memory allocation [NEEDINFO]
console-kit-daemon huge memory allocation
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ConsoleKit (Show other bugs)
18
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-29 05:39 EST by Gabriele Turchi
Modified: 2015-11-08 16:43 EST (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 17:38:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
spike85051: needinfo?


Attachments (Terms of Use)
files from /proc/PID (including all threads) (602.95 KB, application/x-compressed-tar)
2011-08-19 11:39 EDT, Hans Ecke
no flags Details

  None (edit)
Description Gabriele Turchi 2008-11-29 05:39:31 EST
Description of problem:
Under Fedora 10 the console-kit-daemon allocate a huge amount of memory (at least on x86_64 architecture). As an example, on my machine now the allocation is slightly less than 100MB.

Version-Release number of selected component (if applicable):
ConsoleKit-0.3.0-2.fc10.x86_64

How reproducible:
Anytime.

Steps to Reproduce:
1. start a F10 machine
2. do a ps axuw | grep console
3. read the result
  
Actual results:

root      1961  0.0  0.1  98564  2180 ?        Ssl  09:09   0:00 /usr/sbin/console-kit-daemon


Expected results:

about a 10% memory consumption, if I remember correctly from F9.


Additional info:

My apologies for my bad english.
Comment 1 Fedora Admin XMLRPC Client 2009-04-08 13:00:39 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Dan Winship 2009-07-02 10:09:31 EDT
Still a problem in F11. Only on x86_64:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      7274  0.0  0.0 1015948 1992 ?        Ssl  09:50   0:00 /usr/sbin/console-kit-daemon

It is not a slow leak; it grabs all of the virtual memory right at startup. Each thread it creates seems to allocate a ridiculous amount of memory, and it creates a lot of threads.
Comment 3 Edward Rudd 2009-07-23 17:13:55 EDT
what is up with the virtual memory being so huge? it doesn't link to that many executables, but my system it has a 2GB virtual, and a 2.6M resident.  this is a Fedora 11 x86_64 system (4GB of physical Ram).
Comment 4 James Hogan 2010-03-27 06:12:33 EDT
I'm seeing this at the moment on fully updated Fedora 12:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                            
 7600 root      20   0 4019m 3252 1868 S  0.0  0.1   0:00.02 console-kit-dae                    

VIRT=4019m is indeed rather excessive!
Comment 5 James Hogan 2010-04-12 19:36:31 EDT
I've just experienced this randomly again, console-kit-daemon rapidly sucks up all the memory (the system is frozen from thrashing before i get a chance to top and kill it, and I have to wait ages before i get some responsiveness back (perhaps when it runs out of swap space) then I can kill it. Fedora 12 x86_64

Is there anything I can do to get some useful debugging information (I guess i could SIGSTOP it when i get responsiveness back)?
Comment 6 Dan Winship 2010-04-12 20:03:03 EDT
i don't think your bug is related to this one. this is just about the fact that console-kit-daemon on x86_64 uses an implausible amount of VSZ immediately on startup.
Comment 7 Bug Zapper 2010-04-27 08:23:55 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Fedora Admin XMLRPC Client 2010-08-24 18:19:31 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fredrik Chabot 2010-09-08 10:03:20 EDT
F13 x86_64

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  DATA COMMAND                                                                                                                                                 
 1780 root      20   0 2099m 1104  844 S  0.0  0.0   0:08.11 2.0g /usr/sbin/console-kit-daemon --no-daemon
Comment 10 James Hogan 2010-09-18 09:30:44 EDT
How can I stop console-kit-daemon from restarting after I kill it? It's a pain in the arse su'ing and killing it when it makes my system go sluggish every half an hour. Alternatively is there a way to help debug it so we can get this damn problem fixed?

Cheers
James
Comment 11 d. johnson 2010-09-27 21:48:07 EDT
(proxied for new maintainer) Ownership of this package recently changed.  Can you try to reproduce with the F14 version currently in beta?



---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Dan Winship 2010-09-30 09:24:57 EDT
it seems to be fixed in F14:

root      1646  0.0  0.1 184164  3100 ?        Sl   Sep29   0:00 /usr/sbin/console-kit-daemon --no-daemon
Comment 13 James Hogan 2010-10-03 02:29:49 EDT
I can confirm it's fixed in ConsoleKit-0.4.2-2.fc14.
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                           
 1779 root      20   0  111m 2648 2244 S  0.0  0.1   0:00.04 console-kit-dae

It now only has 4 threads instead of over 60 and is only using 111MB of virtual memory rather than 1-4GB.
Comment 14 vxu 2010-10-15 10:03:34 EDT
on 2.6.34.7-56.fc13.x86_64 #1 SMP Wed Sep 15 03:36:55 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

top - 16:00:42 up 1 day,  3:18,  4 users,  load average: 0.00, 0.19, 0.49
Tasks: 143 total,   1 running, 142 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4971308k total,  3277580k used,  1693728k free,   460984k buffers
Swap: 43379432k total,    33800k used, 43345632k free,  2294372k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1993 root      20   0 4019m 1768 1644 S  0.0  0.0   0:01.59 console-kit-dae

 16:02:38 up 1 day,  3:20,  4 users,  load average: 0.00, 0.12, 0.43
Comment 15 James Hogan 2010-11-23 15:46:26 EST
Unfortunately ConsoleKit-0.4.2-3.fc14.x86_64 has regressed and is doing this again! :-(
Downgrading back to ConsoleKit-0.4.2-2.fc14.1.x86_64 fixes it again.
Comment 16 Wayne Hammond 2010-12-04 06:09:22 EST
Recent package upgrade has broken my Fedora 14 86_64 installation.  On start up, the graphics locks up and I can open one application window only.  Opening a terminal session as root and running htop shows 45 instances of /usr/sbin/console-kit-daemon--no-daemon each consuming 4090M of virtual memory.  Killing one instance stops them all but returning to the graphical interface and clicking on any icon causes them all to open again.

This is my main computer and I would like to use it again.  Is there a solution for the problem?
Comment 17 Wayne Hammond 2010-12-04 06:33:06 EST
I attempted to downgrade consolekit using yum and received error ConsoleKit-x11-0.4.2.3.fc14x86_64 @updates Requires: ConsoleKit = 0.4.2.3.fc14

Running yum --skip-broken not effective
Comment 18 James Hogan 2010-12-04 08:02:00 EST
Wayne: try downgrading ConsoleKit-x11 at the same time. the following worked for me:
yum downgrade ConsoleKit ConsoleKit-x11

Unfortunately the previous fix for this was reverted, because some people were having trouble after suspend (which is easily worked around by changing vt and back again). This seems crazy to me since making the system unuseable until console-kit-daemon has to be killed is far worse than having to switch vt twice on resume.

Anyway, hope that helps
James
Comment 19 Wayne Hammond 2010-12-04 08:45:15 EST
I attempted to downgrade consolekit using yum and received error ConsoleKit-x11-0.4.2.3.fc14x86_64 @updates Requires: ConsoleKit = 0.4.2.3.fc14

Running yum --skip-broken not effective
Comment 20 Wayne Hammond 2010-12-04 08:57:11 EST
James,
Thank you for your help.  I tried your solution and was able to downgrade successfully, however, that did not solve the problem.  I can still open only one instance of an application and can navigate the application (Firefox). Attempting to open another app then immediately locks the screens.  Changing to terminal mode and running htop does not have the /usr/sbin/console-kit-daemon--no-daemon entries though.  

I upgraded to Fedora 14 because of this same issue with FC13 a week or so ago and I was sure I had a rootkit or gross misconfiguration somewhere.  Now I see from this thread that this issue is ongoing from FC6 at least.  I sure hope the programmers can find the problem! It is very frustrating.
Comment 21 Wayne Hammond 2010-12-04 09:13:27 EST
Still trying to find the solution, found the entry in htop /usr/sbin/console-kit-daemon--no-daemon entries are still there, but only 5 entries now instead of 45 and the virt values are 243M instead of 4090M.
Comment 22 Frode Tennebø 2011-01-30 16:32:20 EST
As has already been reported, this is an issue with the latest console-kit-daemon in F14 as well.  Downgrading cures the problem for THAT process.

However, *several* others process are exhibiting similar symptoms.  This is the top VIRT users after a fresh reboot and a login::

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28259 ft        20   0 1274m  30m  19m S  0.0  0.8   0:12.64 nautilus --sm-client-id
28242 ft        20   0  746m  15m  10m S  0.0  0.4   0:01.23 gnome-panel --sm-client-id
28218 ft        20   0  673m  13m  10m S  0.0  0.3   0:00.55 /usr/libexec/gnome-settings-daemon
28260 ft        20   0  650m  12m 9836 S  0.0  0.3   0:00.24 gpk-update-icon
28442 ft        20   0  641m  13m  10m S  0.0  0.3   0:00.19 /usr/libexec/clock-applet
28312 ft        20   0  628m  10m 7928 S  0.0  0.3   0:00.13 nm-applet --sm-disable
28298 ft        20   0  571m  11m 8892 S  0.0  0.3   0:00.09 /usr/libexec/gdm-user-switch-applet
28299 ft        20   0  554m 9784 7452 S  0.0  0.2   0:00.07 gnome-volume-control-applet
28562 ft        20   0  543m  19m  15m S  0.0  0.5   0:00.41 kded4
28290 ft        20   0  542m  12m 9820 S  0.0  0.3   0:00.48 gnome-terminal --sm-client-id
28279 ft        20   0  541m  11m 8792 S  0.0  0.3   0:00.97 /usr/libexec/wnck-applet
28278 ft        20   0  519m 8464 6496 S  0.0  0.2   0:00.06 /usr/libexec/trashapplet
28297 ft        20   0  510m 7740 5844 S  0.0  0.2   0:00.09 /usr/libexec/notification-area-applet
28262 ft        20   0  493m 3124 2416 S  0.0  0.1   0:00.04 /usr/libexec/bonobo-activation-server
28239 ft        20   0  465m  11m 8620 S  0.0  0.3   0:00.48 metacity --sm-client-id
28315 ft         9 -11  434m 4800 3504 S  0.0  0.1   0:00.15 /usr/bin/pulseaudio --start

This probably belongs to an altogether different bug-report, but can it somehow be related?  It is also very similar to bug 615505, but I'm using proprietary nVidia driver...  I'm a bit at a loss to what to report this bug against.  Clearly, using this amount of VIRT can not be considered normal behaviour...
Comment 23 Lennart Poettering 2011-02-18 09:15:10 EST
I think this is misleading and caused by the 64 threads we currently are spawning (i.e. the stack reserved for them or something like that).

https://bugs.freedesktop.org/show_bug.cgi?id=17720
Comment 24 Bug Zapper 2011-06-02 14:23:00 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 Dan Winship 2011-06-06 09:14:23 EDT
root      1630  0.0  0.0 2088824 3292 ?        Sl   May31   0:00 /usr/sbin/console-kit-daemon --no-daemon
Comment 26 James Hogan 2011-07-03 16:52:27 EDT
> I think this is misleading and caused by the 64 threads we currently are
spawning (i.e. the stack reserved for them or something like that).

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                  
 1399 root      20   0 4026m 5232 2224 S  0.0  0.2   0:02.41 console-kit-dae                                          

Surely 63MB of (unused) stack space per thread is rather excessive!.
I just killed it and its now using 1527m (which is still excessive tbh), so it obviously isn't expected behaviour

I used to just stick to the older version of console kit that didn't have this bug, but since upgrading to f15 i can't really do that.

James
Comment 27 James Hogan 2011-08-06 17:37:05 EDT
Any word on this bug? It's still happening on a fully updated F15. Does anybody know why the amount of virtual memory that gets mapped varies between runs? Is there any intention to fix it?

Cheers
James
Comment 28 Richard Lloyd 2011-08-19 10:38:23 EDT
This happens on 64-bit CentOS 6.0 and presumably therefore also on RHEL 6.0 (and maybe 6.1?). Virtual sizes of around 1GB for console-kit-daemon on 64-bit CentOS 6.0 desktops and 550MB on 64-bit CentOS 6.0 servers have been seen. Yes, you read that right - the "server" install runs this daemon :-(

What's equally annoying is that you can't just "yum remove ConsoleKit" either - it attempts to also remove 16 other packages on CentOS 6.0 as well! The fix I found is to comment out all the lines in:

/usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service

so it looks something like this:

# [D-BUS Service]
# Name=org.freedesktop.ConsoleKit
# Exec=/usr/sbin/console-kit-daemon --no-daemon
# User=root

I then rebooted the machine (you could probably try restarts of dbus I guess?) and voila - no sign of the daemon running. Initial checking of a desktop without console-kit-daemon running didn't seem to cause any problems (even the virtual consoles via Ctrl-Alt-Funcion_keys worked). What exactly does console-kit-daemon provide (it has no man page :-( ) for the desktop and is it even needed at all for a server?

BTW, I think the severity of this should be above medium - systems like Nagios actually trigger on high virtual sizes like this, so it's not something that can be ignoed.
Comment 29 Hans Ecke 2011-08-19 11:28:41 EDT
When I see this problem in "top", I typically look at the DATA column and that is where I see huge sizes (600MB up to 4GB).

I know that it is often unclear if a given memory size is actually consumed, and how sharing between processes and caches plays in there. But as far as I thought DATA is pretty unambiguous: it is actually consumed memory.

Turns out I'm wrong:

top - 09:24:19 up 2 days, 21:59,  6 users,  load average: 0.04, 0.03, 0.05
Tasks: 394 total,   1 running, 392 sleeping,   1 stopped,   0 zombie
Cpu(s):  0.1%us,  0.1%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   4047916k total,  3323796k used,   724120k free,   552536k buffers
Swap:  8388604k total,     2004k used,  8386600k free,  1487364k cached

  PID USER      PR  NI DATA  VIRT  RES  SHR S %CPU %MEM   TIME P COMMAND                                                                  
 4870 root      20   0 4.0g 4087m 1432 1432 S  0.0  0.0   0:00 1 /usr/sbin/console-kit-daemon --no-daemon                                 

It is quite impossible for console-kit-daemon to have consumed 4GB here, since the whole system is currently only using 3.17GB.

I'm attaching several files from /proc/PID. Could somebody more knowledgeable tell me where this 4GB number comes from and how much the daemon is _actually_ using?
Comment 30 Hans Ecke 2011-08-19 11:39:46 EDT
Created attachment 519061 [details]
files from /proc/PID (including all threads)

This is a tar archive which contains /proc memory information from all threads of a console-kit-daemon process. The process shows up with a DATA and VIRT size of 4GB in top, but that is impossible: the whole computer contains only 4GB of memory and there is a KDE session running just fine.....
Comment 31 Dieter Vandenbroeck 2012-04-16 15:46:47 EDT
Fedora 16, x86_64


[Dieter@DieterLaptop ~]$ ps axuw | grep console
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1453  0.0  0.0 2085476 1536 ?        Ssl  Apr12   0:01 /usr/sbin/console-kit-daemon --no-daemon
Comment 32 Fedora End Of Life 2012-08-07 15:20:32 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 33 James Hogan 2012-08-08 04:12:38 EDT
As Dieter Vanderboeck said, it happens on Fedora 16 as well, so can somebody with permission please re-open this bug and change the version to F16.

$ ps axuw | grep console
root      1686  0.0  0.0 2085456 2068 ?        Ssl  Jul16   0:00 /usr/sbin/console-kit-daemon --no-daemon
Comment 34 Stan King 2012-08-08 04:25:41 EDT
As Fedora 16 is well on its way to the dustbin of history, here's a data point from Fedora 17, where the behavior at least looks similar:

$ ps axuw | grep console
root      1047  0.0  0.0 2085276 3716 ?        Ssl  Aug03   0:01 /usr/sbin/console-kit-daemon --no-daemon
Comment 35 Pedro L. 2012-08-19 15:32:55 EDT
Same on CentOS 6.3:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2159 root      20   0 2035m 5812 2416 S  0.0  0.1   0:00.35 console-kit-dae

In my case, as well the others in this thread (pun intended), even though VIRT was huge, the RSS is VERY SMALL.  And in my case, the swap used is 0, so this doesn't really appear to be using much virtual memory (RAM or swap).  

I thought maybe it was doing some mmap() calls, but I don't see any mapped files in lsof.

From /proc/2159/status:

VmPeak:  2136488 kB
VmSize:  2084416 kB
VmLck:         0 kB
VmHWM:      5812 kB
VmRSS:      5812 kB
VmData:  2046508 kB
VmStk:        88 kB
VmExe:       132 kB
VmLib:      4796 kB
VmPTE:       264 kB
VmSwap:        0 kB
Threads:        64

Maybe this is a clue from http://ewx.livejournal.com/579283.html:

VmSize includes pages with PROT_NONE protection (i.e. which allow none of read, execute or write). These don’t consume any RAM or swap, just address space, so this figure can be very inaccurate if used as an estimate for anything other than address space. For instance on amd64 the runtime linker will add 2MB per shared library. The Boehm GC also uses this feature to reserve address space, making the figure to some extent a peak-usage figure rather than a current one.

--PL
Comment 36 Valent Turkovic 2013-01-17 10:19:03 EST
Is there a workaround?

Can I just disable console-kit-daemon? How?
Comment 37 Artem S. Tashkinov 2013-01-18 01:30:19 EST
This bug should be closed as VIRT doesn't reflect real memory usage by the application.

Real memory usage is the RES column in the `top` output and it's totally sane and normal for most people in this bug report.
Comment 38 James Hogan 2013-01-18 02:13:35 EST
(In reply to comment #37)
> This bug should be closed as VIRT doesn't reflect real memory usage by the
> application.

It wouldnt annoy people unless it had a noticable effect on performance and if killing it didm't help.. so either youre wrong or the problem isnt understood properly.

> 
> Real memory usage is the RES column in the `top` output and it's totally
> sane and normal for most people in this bug report.

Using that much virt isnt sane. What could it possibly need 64meg virt for each console for, especially if none of it is being used?
Comment 39 Artem S. Tashkinov 2013-01-18 03:52:49 EST
(In reply to comment #38)

Run `free`

Kill any such app which has an insane VIRT size.

Run `free` again.

Check how much RAM has been freed. Correct your thinking.

P.S. This bug report is invalid and needs to be closed.
Comment 40 James Hogan 2013-01-18 04:07:23 EST
(In reply to comment #39)
> (In reply to comment #38)
> 
> Run `free`
> 
> Kill any such app which has an insane VIRT size.
> 
> Run `free` again.
> 
> Check how much RAM has been freed. Correct your thinking.
> 

If that's so then like I said, the reason for the performance impact is not properly understood.
Comment 41 Dan Winship 2013-01-18 09:37:25 EST
This is fixed in f18 at least, by virtue of the fact that console-kit-daemon no longer exists, presumably having been absorbed into systemd or something, and whatever it is that replaced it now using saner APIs that don't require it to spawn 64 threads.
Comment 42 Brian J. Murrell 2013-03-04 22:32:39 EST
If console-kit-daemon no longer exists in F18 how come my F18 machine shows this:

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           
11684 root      20   0 4090m 3636 2632 S   0.0  0.0   0:00.14 console-kit-dae   

So yeah.  Almost 4GB of RAM (not VM!) being consumed by something that (a) should not require anywhere near that amount of RAM (or VM) and (b) something that is not supposed to exist even.

RPM says it comes from this package:

$ rpm -qf $(which console-kit-daemon)
ConsoleKit-0.4.5-3.fc18.x86_64

Which looks like an F18 package to me.  How does this square up with comment #41?

But more importantly, given that this problem has existed for 8 releases now, is there any chance of it being fixed?
Comment 43 Hans Ecke 2013-03-04 23:05:17 EST
Hi Brian,

Linux memory usage statistics are not trivial. If you malloc 4GB of RAM then - if my understanding is correct - the DATA and VIRT column for your program will show it as using 4GB. However, they will only be actually consumed if you write to those 4GB.

You can think of it like a sparse file. If you create a file, then seek to a position 4GB from the start and write one byte, the intervening 4GB will not actually be written to disk or indeed consumed.

In your example above console-kit-daemon is not using 4GB of RAM. It requested them but never used them, and never will. This is ugly but not a bug.

Hans
Comment 44 Brian J. Murrell 2013-03-04 23:26:44 EST
Hans,

Yes, I understand how virtual memory works and that most (all even) of what is malloc'd could very well be in VIRTual memory and not RESident in real memory.  However as you can see from comment 42, on my machine, console-kit-daemon is using 3.6GB of RESident memory of the 4.1GB of VIRTual memory that's been allocated.

3.6GB of real memory for a daemon.  That's just insane!
Comment 45 Fedora End Of Life 2013-07-04 02:42:37 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 46 Burhan Ali 2013-07-04 02:48:00 EDT
Given comment 42, can someone please update the version to 18?
Comment 47 Fedora End Of Life 2013-08-01 14:19:01 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 48 Brian J. Murrell 2013-08-01 14:36:37 EDT
Per comment 46 which references comment 42, this problem is still being seen on Fedora 18 and there was a request to update the version and that didn't happen.

Can we please have this ticket reopened and the version updated to 18?
Comment 49 Fedora End Of Life 2013-12-21 09:51:05 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 50 Randell Jesup 2014-01-16 17:06:13 EST
Still the case on F19: VM 4G, resident 1.5MB

Certainly is confusing to people.  For comment 42, I'll note that it has 4GB of address space in use, and 3.6 MB (not GB) is resident.

And the perf issues may relate to managing the address space/page tables/etc, even if there's no ram backing them at the moment.  Just a guess.
Comment 51 Fedora End Of Life 2014-02-05 17:38:18 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 52 Richard Jasmin 2015-11-08 16:43:58 EST
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

SURE. How about 22.

firefox was getting sluggish and feathercoid (yes the daemon, not the wallet qt app) is reporting a boost error after init.

Now, keep in mind I have proc limits set thru the security files.Initially they were too low.This is forkbomb double prevention. The initial setting for this is fine (for red hat products) but does not limit amount of running or forkable processes. Self-bomb if you dont believe me.

diagnosing with:
ps -eLF

seems to show the problem again.The system has been up for awhile but I reboot often.For something that is supposed to be part of something else, someone needs to look at whats going on.

root      2193     1  2193  0   64 1051679 6840  7 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2194  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2195  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2196  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2197  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2198  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2199  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2200  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2201  0   64 1051679 6840  7 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2202  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2203  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2204  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2205  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2206  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2207  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2208  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2209  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2210  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2211  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2212  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2213  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2214  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2215  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2216  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2217  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2218  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2219  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2220  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2221  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2222  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2223  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2224  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2225  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2226  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2227  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2228  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2229  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2230  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2231  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2232  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2233  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2234  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2235  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2236  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2237  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2238  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2239  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2240  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2241  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2242  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2243  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2244  0   64 1051679 6840  2 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2245  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2246  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2247  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2248  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2249  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2250  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2251  0   64 1051679 6840  3 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2252  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2253  0   64 1051679 6840  4 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2254  0   64 1051679 6840  5 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2255  0   64 1051679 6840  6 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon
root      2193     1  2256  0   64 1051679 6840  1 Nov02 ?        00:00:00 /usr/sbin/console-kit-daemon --no-daemon

thats a LOT of running processes for being "not required to function for X logins"

Note You need to log in before you can comment on or make changes to this bug.