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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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).
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!
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)?
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.
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
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
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
(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
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
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.
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
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.
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?
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
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
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.
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.
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...
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
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
root 1630 0.0 0.0 2088824 3292 ? Sl May31 0:00 /usr/sbin/console-kit-daemon --no-daemon
> 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
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
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.
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?
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.....
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
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
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
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
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
Is there a workaround? Can I just disable console-kit-daemon? How?
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.
(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?
(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.
(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.
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.
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?
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
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!
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.
Given comment 42, can someone please update the version to 18?
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.
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?
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.
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.
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.
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"