console-kit-daemon spawns too many threads

[Michael Nagel]

since upgrading to gutsy beta htop shows about fifty processes like the following

pid user pri ni virt res shr s cpu% mem% time+ command
7582 root 23 0 7456 2016 1336 s 0.0 0.2 0:00.00 /usr/sbin/console-kit-deamon

It maybe the case that console-kit-daemon starts a thread for each console that can theoretically exist. On Linux (/usr/include/linux/vt.h) MAX_NR_CONSOLE is defined to be 63.

Note that those processes do not show up in DEFAULT top or ps output --BUT-- if you run either of those tools with the -H parameter, so as to display all the threads of a process, then they do show up.

[Michael Nagel (nailor)]

just checked on another computer, exactly the same thing there.
the processes are kill-able, i.e. 'sudo killall console-kit-deamon' succeeds and htop shows 50 processes less after that.

[Loic Nageleisen (lloeki)]

I'm experiencing this too, on a fresh Gutsy install.

'ps -e | grep console-kit' only shows one process while htop shows many.
htop tree mode shows them all spawned from init.

fast-user-switch applet is removed from panel as I don't use it (one-user laptop).

[NiklasW (falken)]

Is there a work around for this bug? I have the same issue on my system, 62 process of /usr/sbin/console-kit-deamon.

If I remove the fast-user-switch applet will that stop the console-kit-deamon problem? (I did not know that I had this on my panel) will check later if that is the case..

I understand that 'sudo killall console-kit-deamon' will clean out the processes for now, but I guess they will come back...

The thing is that i am the only* user. Only= I have some other users like mythtv and so on. I only use the via the console, then via 'sudo su mythtv'.

[Michael Nagel (nailor)]

hiding userland threads (within htop) seems to be a workaround

[11Touche (11touche)]

Same here, counted 60 console-kit-daemon processes.
I killed them under htop and it doesn't affect my machine for now.
Hope it will be corrected, I can't manage to figure 60 running instances of a process could be call as a normal thing

[Audric Schiltknecht (audric-schiltknecht)]

Same thing here, 61 instances of "console-kit-daemon". Removing the package "consolekit" has fixed it, but I have only one user on my computer.

[GarthPS (garthps)]

I have exactly the same problem... and i think a lot of person as the same without knowing that..

[Thomas Babut (thbabut)]

I can confirm this bug/problem. I am the only user on my computer and this process shows up many times.

[GerhardGaußling (ggrubbish-web)]

I installed today htop, and noticed this behabior too.
Please read this:
https://wiki.ubuntu.com/UnifiedLoginUnlock
http://lists.freedesktop.org/archives/hal/2007-January/006996.html

[Jonathan Rogers (jonner)]

It seems that by default, htop lists each thread on a separate line, while other utilities don't. If you want to see one line for each process, hit F2, then enable the "Hide userland threads" option in the "Display Options" menu.

[marcobra (Marco Braida) (marcobra)]

Confirmed here with Ubuntu Hardy 8.04 fully update/upgraded and with htop 0.6.6 - (C) 2004-2006 Hisham Muhammad.
The htop list a lot of duplicate rows about the unique ( verified with ps command ) process, with different htop PID number:
/usr/sbin/console-kit-daemon (60 rows)

same for the unique process :
/usr/sbin/apt-cacher-ng (3 rows)
with different htop PID

Top works good and i see only a process for console-kit-daemon and for apt-cacher-ng

*** It seems that by default, htop lists each thread on a separate line, while other utilities don't. If you want to see one line for each process, hit F2, then enable the "Hide userland threads" option in the "Display Options" menu.

Works good

Hope this helps, thank you.

[mehturt (mehturt)]

I thought this bug is about "why the f**k has console-kit-deamon 60 threads"..

[Jonathan Rogers (jonner)]

Actually, the purpose of this bug report is unclear to me. It says that console-kit-daemon has over fifty processes, which is not true. The reporter says that htop's display is different from other utilities, like ps, which I've found to be true. In fact, I've found htop's display of multiple threads in a single process to be misleading and possibly buggy. So, to me it isn't clear whether this is about a problem with console-kit-daemon or htop. It's possible that there are different problems with each, but in any case, a bug report probably needs to state more clearly where the bad behavior is.

[Nick Fishman (bsdlogical)]

I noticed this bug today, too, on a multiuser LTSP system running Gutsy.

Like others have said, ps doesn't show multiple processes of console-kit-daemon. In my case, htop showed a range of PIDs from about 6188 to about 6250 (somewhere along those lines), whereas ps only showed one single PID.

Out of curiosity, I tried killing one of the PIDs that wasn't listed in ps, and it closed down console-kit-daemon. I no longer saw the bunch of process in htop, nor did I see the single process in ps.

This may be an issue with the way console-kit-daemon handles threads, or it might be an issue with the way htop handles thread display in some cases. I'm not sure. I'm reluctant to say that it's a bug because when I checked /proc, I saw only the PID listed by ps. It seems better to trust /proc than htop, if differentiating between the two becomes necessary.

[Evan Goers (megatog615)]

Can anyone explain why console-kit-daemon needs 60 threads? I think 4 would be good enough.

[Christian Schürer-Waldheim (quincunx)]

I've changed the header of this bug to be more concise about the actual problem.

The question is, as Evan said before: Why does console-kit need so many threads.

[Marco Scholl (traxanos)]

I have the same! Why it need so much?

[Joel Wirāmu Pauling (aenertia) (aenertia)]

Console kit crashes on hardy beta4 amd64. Causing all shift/ctrl key sequences to be unavailable.

[Jonathan Rogers (jonner)]

Crashing is a completely different symptom from anything described in the bug description or discussion so far, so that really needs a new bug report.

[Lynoure Braakman (lynoure)]

pstree on my system shows about 60 console-kit-daemon threads on my up-to-date Hardy as well. All except couple of the last ones have pids in perfect sequence. Does console-kit-daemon start a fixed number of them when starting up, whether so many are needed or not?

[Loye Young (loyeyoung)]

The problem, methinks, is a memory leak in the code, not too many spawns.

If so, it may explain Bug 132029.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

[Ali Sheikh (asheikh)]

This looks like an upstream bug: console-kit starts a thread for each console that can theoretically exist. On Linux (/usr/include/linux/vt.h) MAX_NR_CONSOLE is defined to be 63. console-kit apparently wants to monitor each of the consoles to see if anyone ever logs in on these consoles or not.

On my Ubuntu system, I can only see VTs 1-7 enabled. I have only ever logged onto VT1 and VT7. All the remaining threads are useless and are wasting system resources.

[Aeffenwell (wilfried-chauveau)]

Hi,
I've noted that i had this problem for other programs like skype, firefox (and npviewer)
in the setup, i have checked "Hide userland threads" and it solve the issue,
and for console-kit-daemon too.

I don't know if it can help.
Bye

[Loye Young (loyeyoung)]

>i have checked "Hide userland threads" and it solve the issue,

Hiding the threads doesn't solve the issue; it merely hides the problem.

The problem is that the threads are running, not that the list of running
threads is too long.

On Mon, Apr 28, 2008 at 4:58 PM, Aeffenwell <email address hidden>
wrote:

> Hi,
> I've noted that i had this problem for other programs like skype, firefox
> (and npviewer)
> in the setup, i have checked "Hide userland threads" and it solve the
> issue,
> and for console-kit-daemon too.
>
> I don't know if it can help.
> Bye
>
> --
> console-kit-deamon spawns too many threads
> https://bugs.launchpad.net/bugs/148454
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
[phone]
<email address hidden>

[Aeffenwell (wilfried-chauveau)]

Ok, i understand, sorry
so, for the bug tracking, I have this issue since feisty fawn.

[Jonathan Rogers (jonner)]

While it may be technically correct that spawning a thread for each potential virtual console wastes resources, does anyone have an estimate of how much? On my system, console-kit daemon (the entire process with all umpteen threads) is using about 2.5MiB of resident memory, of which about 1.7MiB is shared with other processes. This is pretty modest compared with many other standard Ubuntu processes like hald (4.5MiB), pulseaudio (6.5MiB), and Xorg (56.7MiB). If I wanted to strip the system down to the bare essentials to require less RAM, I'd completely disable things like console-kit-daemon, hald, cupsd and other daemons that aren't absolutely essential. However, on a typical modern system with 512MiB of RAM or more, 2.5MiB just isn't very significant. If someone were able modify console-kit-daemon so that it used only 1MiB to do the same job, that would be great, but I think this bug report with its hopelessly vague title (how many threads is too many?) isn't likely to do anything but waste time.

[Loye Young (loyeyoung)]

@Jonathan Rogers --

There are at least two major flaws in your analysis. First, your analysis presumes to know ex ante the configuration of the computer and the use to which the package will be put. Second, it does not take into account the need for simultaneously managing multiple users and multiple hardware connections to the computer, in both graphical and console modes.

Various configurations--

Using Linux as a desktop platform provides a degree of flexibility and power that was hitherto simply unavailable. The significant advances in software technology is fueling the explosive growth of recycled, mobile, and embedded devices, most of which are running or are planned to be run on Linux.

The overall efficiency gains are attributable to much more than just the kernel. Because open-source developers have a penchant for eliminating inefficiencies and wasted resources, the entire software stack is significantly faster and lighter than legacy operating systems. It is true that resource-restrained systems must make often difficult choices, but part of the work we do is to give the community more choices in order to solve common problems.

One example of an effort to deliver the desktop to low-resource systems is the Xubuntu distribution, which is specifically designed to run on systems with 256M of RAM. Other low-resource desktop solutions are, e.g., DSL, Puppy Linux, Fluxbuntu, aLinux, Zenwalk, DeLi Linux, Wolvix. My company is currently developing a desktop solution to manage servers with a graphical interface.

In such use-cases, every megabyte of wasted resources makes a difference, and eliminating the waste is a never-finished project. Eliminating 2.5 MB of resource usage from one process is often a terrific improvement. In addition, each freed thread reduces state usage, which can make a significant improvement in performance in many situations.

Console-kit is intended to solve in a platform-independent manner several problems related to the management of multiseat configurations. See http://lists.freedesktop.org/archives/hal/2007-January/006996.html. As desktop environments are coalescing around the DBUS architecture, common solutions such as console-kit will be invaluable to interoperability among applications and among desktop environments. Because the common solutions will be used in such disparate situations, resource utilization must be zealously optimized throughout the stack.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

[Jonathan Rogers (jonner)]

Sounds great, Loye. I look forward to your memory footprint reduced console-kit-daemon. I too am interested in multiseat configurations. I've experimented with a configuration that uses Xorg to create a separate screen on each of two ports of my video card and an instance of Xephyr running on top of each. That approach works, but is far from ideal in both functionality and memory footprint.

I still don't think console-kit-daemon's footprint should be nearly as high priority as the X server's, which is 20 times larger on my system. Of course, a lot of portable and embedded systems use GUIs with no X server or a very small one, like tinyX, but those aren't typically multi user. For comparison's sake, what is the smallest footprint you've seen of a functional X server on a system that had multiple users in a way that needed console-kit-daemon?

I'm sure it's possible to reduce the memory footprint and other resources of console-kit-daemon, but I haven't seen any strong evidence that it deserves as much attention as much more demanding daemons and apps on an Ubuntu system. I'm also curious about how a completely dormant thread reduces performance of the system.

But the main problem with this bug report is that it's too vague. If console-kit-daemon can be made to only track the Linux virtual consoles in use and that decreases footprint and improves performance, this bug report should say so. However, currently it says nothing about what the threads are used for or what would be an appropriate number of threads.

[Loye Young (loyeyoung)]

I've written an email to the author of ConsoleKit inquiring about the issue. What follows is the text of my correspondence:

<quote>
>Mr. McCann,
>
>Users on Ubuntu systems (myself included) are finding that ConsoleKit generates several dozen processes and doesn't seem to release them.
>Although no one of the processes takes up much memory or state, the aggregate amount is significant, especially on resource constrained
>systems.
>
>Is this expected behavior? If yes, could you shed some light on why so many processes and threads need to remain open? If no, do you have any
>idea whether the problem is in ConsoleKit or in the Ubuntu implementation of ConsoleKit?
>
>From what I've read about ConsoleKit, it seems to be a sensible solution to managing users and hardware access for desktop and other GUI
>applications. However, the sheer number of running processes has many asking whether the game is worth the candle. Your guidance on the
>relative benefits and costs and on expected implementation of ConsoleKit would be much appreciated.
>
>See the forum discussion at http://ubuntuforums.org/archive/index.php/t-556272.html, and the bug report at
>https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/148454.
</quote>

Happy Trails,

Loye Young

[Loye Young (loyeyoung)]

@ Jonathan Rogers

>However, currently it says nothing about what the threads are used for or what would be an appropriate number of threads.

Of course, it's not documented, so no one knows, which is why the bug report exists in the first place. Experienced users and system engineers know that generally something is wrong if several dozen identical, dormant processes are running in userspace with no apparent usefulness.

>I haven't seen any strong evidence that it deserves as much attention . . . .

I'm not exactly sure what you are trying to accomplish in this thread. If this issue isn't worthy of attention, why are you paying it so much? Saying that there are other problems to solve is stating the obvious and not helpful to solving any of them. If you know of a reason this problem should not be fixed, do tell. If you have other helpful information, share it. If you have solutions to this or other problems in the stack, go solve them.

Said another way, if you know of bigger fish to fry, perhaps you should get your skillet out and fry them.

Happy Trails,

Loye Young

[Vladimir (snape)]

I have the same problem. I was trying to uninstal consolekit, but it is bindet to hundreds other apps. Impossible to remove. If I kill it, it restarts automatically.

This bug is very annoying. I never need to switch user, I am the only one here and yet I need to run this absurd application. I have only 512MB RAM and the performance is significantly slower with 60 useless threads.

Btw. it also shows on gkrellm. And yes, it was on Gutsy Gibbon as well, but on that version it was possible to remove the consolekit without too much trouble. Not any more. :-(

So does anyone have any suggestion, how to get rid of this? Or do I need to switch to openSuse or something similar because of this?

[Michael Nagel (nailor)]

(i am the original reporter) original bug report was, that i thought htop shows incorrect data (as ps and top did not show the processes). it became clear, that this is not the case, as the processes ARE running.

htop is (at least a little bit) unusable showing that many spam threads. but one can hide them by setting the "hide userland threads" within htop. on the other hand i still wonder if it is necessary for a little tool like console-kit-deamon to launch a full-blown thread for every single console that could theoretically exist. but that is probably a seperate bug.

for now i am ok with the fact that htop does not show incorrect data and have showing userland threads disabled, just as it is default with ps and top.

[Martin von Wittich (martin.von.wittich)]

I have no idea why you are all so agitated by this. If the console-kit-daemon developers think that it makes sense for it to spawn ~60 threads, then so be it! It may be alright to ask for the reason behind this and to suggest to reduce the thread count, but _please_ don't snivel such nonsense as "the performance is significantly slower with 60 useless threads". [@Vladimir: whatever the reason may be for your computer running slow, it is most probably not console-kit-daemon. If you're having problems, watch you Load Average in htop, watch your iowait in "vmstat 1", and so on; a much more probable issue would be trackerd.]

As far as I'm concerned, this is neither a bug in console-kit-daemon nor htop.

BTW: if you want to see the threads in ps, use "ps xaH|grep console".

[aquo (sbauch)]

Martin, could you please proof that the 60 console-kit-threads don't slow down a computer? Please consider slower computers with low ressources as well.

[aquo (sbauch)]

I have prepared a simple patch (only basic functionality, no integration in g_object style programming, parameter passing with a global variable) to limit the number for MAX_CONSOLE consolekit can use. It is more a feature request than a solution.

You can pass a parameter --limit-vts N or -l N to the console-kit-deamon to limit the maximal number of VTs monitored. The patch reduced the amount of threads spawned. As I am using this only on a single user machine nothing else is tested.

[Martin von Wittich (martin.von.wittich)]

You should file a bug on the ConsoleKit bugtracker and post your patch there: https://bugs.freedesktop.org/enter_bug.cgi?product=ConsoleKit

[Nick Demou (ndemou)]

This bug report seems more like asking:

1) Is it normal for Console-Kit-Daemon to spawn ~60 threads

2) If htop reports 0.2% usage per thread does this mean that those 60 threads eat-up 0.2%*60=12% of RAM?

I've tried to convert it to a Question but launchpad returned an error

[Nick Demou (ndemou)]

nobody has shed some light as to what is wrong with console-kit-deamon spawning 60 threads. Until we can't define what's wrong with it this can't be considered a bug.

Of course there were some statements regarding system resources that get eaten up by those threads but except from memory they were really vague and unfounded. Regarding memory usage, although I'm not an expert, I know enough to understand that taking the 0.2% per thread, that htop reports under the MEM% heading, and multiplying by 60 to arrive to the conclusion that CKD eats up 12% of your RAM is far from a safe assumption

[Lynoure Braakman (lynoure)]

Mr. Demou, if you are, as you said, not an expert and not sure if spawning 60 threads is normal and correct for console-kit-daemon in Ubuntu or not, please don't mark the bug invalid but consider Incomplete as a better choice. Maybe even consider finding out these things from the developers or upstream before you tell all the people commenting on this bug that they have been just wasting their time.

[Stefan Nuxoll (snuxoll)]

Spawning 60 threads when no more than 5 will be used shoud be considered a bug. Plain and simple.

[Adam (adam-redhat-bugs)]

Description of problem:
I have upgraded a new F9 system to Rawhide. Whereas other recent bugs related to switching runlevels, I have seen the creation of lots of console-kit-daemon processes when going straight into runlevel 5. As of this writing, there are 62 such processes on the system, which has been up 30 minutes.

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

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

excerpt of pstree output:

init─┬─/usr/bin/sealer
     ├─NetworkManager───{NetworkManager}
     ├─acpid
     ├─anacron
     ├─atd
     ├─auditd─┬─audispd───{audispd}
     │ └─{auditd}
     ├─avahi-daemon───avahi-daemon
     ├─bonobo-activati───{bonobo-activati}
     ├─clock-applet
     ├─console-kit-dae───62*[{console-kit-dae}]
     ├─crond
     ├─cupsd
     ├─2*[dbus-daemon───{dbus-daemon}]
     ├─2*[dbus-launch]

[Matthias (matthias-redhat-bugs)]

This is not a bug, it is working around the limitiations of the linux vt system.
These are threads, one for each vt, sleeping in VT_WAITACTIVE.

[Jason (jason-redhat-bugs)]

Created attachment 336537
Patch for ConsoleKit 0.30 to remove so many threads

This patch changes ConsoleKit to use an new VT ioctl and wait on a terminal switch without requiring a thread for every possible VT.

[Jason (jason-redhat-bugs)]

Created attachment 336538
Kernel patch to add new VT ioctl.

This patch must be added to the kernel to support the previous patch for ConsoleKit. Basically we add a VT_WAITSWITCH ioctl which sleeps until any virtual console switch occurs; this allows ConsoleKit to only use one thread to wait, and it uses the VT_GETSTATE ioctl to determine the active VT (as with Solaris implementation).

[Topher (topher-redhat-bugs)]

FYI: I'm seeing the same thing in F12. (63 console-kit-daemon processes)

[Colin O'Dell (colinodell)]

I'm experiencing the same "issue" on a 9.04 web server. I've got a cron job killing all console-kit-daemon processes daily to recover RAM. The first time I did this (with 20 days uptime) I saw over 300MB of memory freed up! CPU usage is negligible, since most of the threads aren't active. This eased my concerns a bit, but I'd still recommend doing a "sudo killall console-kit-daemon" to keep memory usage down.

[A. Denton (aquina)]

I'm a computer science student (graduation next term) and have recently reviewed the consolekit code. The kernel and consolekit patches issued here are fine so far. In my opinion the only reason why this is still unfixed are the consolekit maintainers on the one hand and the problem with backports on the other hand. I realized that this bug was reported when consolekit was in v0.2.x and now it's v0.4.x since karmic I guess.

Nevertheless I'd like to mention that creating lots of (60+) threads has nearly no performance impact on a computer system with a few hundred megs of RAM and say 1 GFLOPS (todays systems have about 20-30 times as much as that). There is nothing to switch (contxt change) besides the fact that these idle threads do nothing most of the time (state: S).

The whole thing is mostly an architectural one. Some people don't like to see too manny threads listed in their favourite application or that way of console usage when it comes to the code. I can only partially agree with that since users have to thake care of their interface configuration themselves. Regarding the architectural change I agree with that but still have to emphasize the low impact on todays computers and GNU/Linux operating systems with it's modern kernels. Some people reported about consolekit wasting computing time or memory. I think this is related to different bugs either in consolekit other parts of the operating system.

Fixing it by exiting the code in within the main()-function is not an appropriate solution as well as replacing the binary isn't. You will end up possibly crashing your system with that (at least parts of the GUI). Also it is a bit difficult to apply the fixes to older versions of Ubuntu like 8.04 LTS for e.g. since a kernel patch is involved. Backports need to be tested. My personal recommendation is to do one thing about this "bug" -- nothing.

[William Jon McCann (william-jon-mccann)]

Lennart, any chance you can make a patch to use this new functionality?

[Rez (rez)]

This 3+ years old bug (or feature...) is still giving many people headaches: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/148454

Any chance to see those useless processes go away in our lifetime?

If Alan gave up maintainership can someone please work on a fixed version of that ck autoconfigure patch, or something different, an hack, anything?

[Lennart-poettering (lennart-poettering)]

(In reply to comment #16)
> Any chance to see those useless processes go away in our lifetime?

They aren't processes, they are threads. And they serve a purpose.

The current behaviour might be suboptimal, but it is correct, as such it would be nice if this is fixed but we certainly have more burning issues to fix.

Also note that whatever the LP bug says about the 63 threads wasting oh so much resources, that is simply nonsense, the folks complaining have no clue what they are speaking of.

> If Alan gave up maintainership can someone please work on a fixed version of
> that ck autoconfigure patch, or something different, an hack, anything?

The stuff is in the kernel. It's just a matter of someone writing a patch for CK. Would be wonderful if you and your Ubuntu friends might contribute good code once in a while instead of just complaining for 3 years straight... ;-)

Anyway, I might come up with a patch eventually, but it is not a priority item on my todo list, sorry.

[Rez (rez)]

(In reply to comment #17)

Maybe we're complaining because we're users, not developers. I didn't *choose* to install consolekit in the first place... but I have to, or stay away from X/Gnome/nm and who knows what else.

Anyway, several console-kit/kernel patches *have* been proposed on LP by those "ubuntu friends" you were talking about; unfortunately, limiting consolekit seems to cause other problems. That's why most people are just waiting it to be fixed in upstream.

[Lennart-poettering (lennart-poettering)]

(In reply to comment #18)
> Anyway, several console-kit/kernel patches *have* been proposed on LP by those
> "ubuntu friends" you were talking about; unfortunately, limiting consolekit
> seems to cause other problems. That's why most people are just waiting it to be
> fixed in upstream.

if the patches are good, why aren't they submitted upstream?

[syntag (lotekware)]

"My personal recommendation is to do one thing about this "bug" -- nothing."

I disagree. The insane amount of threads spawned by consolekit slows down sorting of the red-black tree in CFS (default scheduler in Ubuntu) AND eats up unnecessary resources (a few megs of RAM, and probably some cpu). Actually the threads themselves are unnecessary. It IS a bug, and it should be fixed since we are practically forced to use consolekit -- remove it and you have an unstable system.

[Gregor Müllegger (gregor-muellegger)]

I totally agree on syntag's post. I have from time to time very bad performance inpacts that are caused by consolekit. It eats up many CPU cycles and slows down the whole system remarkably. RAM is not an issue since my system is not swaping while this happens. After I "pkill -9" all the processes the system gets immediatly much more responsive.

I assume that its not because of my hardware is being slow. I have a Intel i920 with four physical cores. As mentioned above, the slowdown is not always the case. It happens only from time to time.

[rifter (rifter0x0000)]

(In reply to comment #17)
> (In reply to comment #16)
> > Any chance to see those useless processes go away in our lifetime?
>
> They aren't processes, they are threads. And they serve a purpose.
>
> The current behaviour might be suboptimal, but it is correct, as such it would
> be nice if this is fixed but we certainly have more burning issues to fix.
>
> Also note that whatever the LP bug says about the 63 threads wasting oh so much
> resources, that is simply nonsense, the folks complaining have no clue what
> they are speaking of.
>
> > If Alan gave up maintainership can someone please work on a fixed version of
> > that ck autoconfigure patch, or something different, an hack, anything?
>
> The stuff is in the kernel. It's just a matter of someone writing a patch for
> CK. Would be wonderful if you and your Ubuntu friends might contribute good
> code once in a while instead of just complaining for 3 years straight... ;-)
>
> Anyway, I might come up with a patch eventually, but it is not a priority item
> on my todo list, sorry.

I have to disagree with the claim that resources are not being eaten up by console-kit-daemon. According to a top I did on a system that was recently having memory issues, the 64 console kit processes were using over 7.6GB of memory (122+MB each). as someone else has pointed out, patches have been proposed for this. Maybe they were not "good code," I haven't read it. It would be interesting to find out why there need to be so many processes at outset rather that spawning a more conservative number of processes (or threads as the case may be; although each one seemed to have a distinct pid) to me even using 122MB total would be silly; what is this program doing that requires so much RAM?

[rifter (rifter0x0000)]

I am running Ubuntu 9.10 on AMD 64-bit and I have this bug. I disagree with those who say the resource waste from this bug is negligible because at least in my case I have 64 instances of this process, each of which are using over 122MB of RAM, 117MB of which is virtual. That's a total of over 7.6GB for a set of processes that have no discernable purpose. If it's supposed to be monitoring terminals including pseudoterminals, it t seems strange that it would be starting so many instances. It's even more egregious if it is supposed to be monitoring real ttys.
Even if you wanted to monitor a bunch of terms, wouldn't it make more sense to spawn a more conservative, perhaps configurable, number of processes at the outset and spawn more as needed? That's basically the model for programs like Apache and, if memory serves, sshd. If it's good enough there it would seem it should be good enough here.
At the very least we should have a better explanation of why this daemon is deemed necessary so we can seek alternatives, or have some workaround. I'll try killing the processes, but it seems to me that just killing off all the processes for a program that is poorly understood, at the very least killing all instead of some, is a poor administrative solution.
I've been having performance problems as well, and I have to wonder if at least part of the problem is not due to this. At the very least that much memory being used is a problem, and I originally sought out answers when I needed to free up some memory.

[Jakob Unterwurzacher (jakobunt)]

> I have 64 instances of this process, each of which are using over 122MB of RAM, 117MB of which is virtual.
> That's a total of over 7.6GB for a set of processes that have no discernable purpose.

I don't think so. Where do you have that numbers from?
Take a look at console-kit-daemon in gnome-system-monitor, column
resident memory. Should show something below 3MB. Note that this
includes all the 64 threads!

> I've been having performance problems as well, and I have to wonder if at least part of the problem is not due to this. At the very least that much memory being used is a problem, and I originally sought out answers when I needed to free up some memory.

Sorry, but console-kit-daemon is not the problem in this case.

[Peshko R. (peshko-us)]

Wow...I am surprised that after 2.5 years and multiple releases we are still talking about this bug...I had it in 9.10 64-bit and I upgraded to 10.04 64-bit and still have it...Was it gutsy that it was reported on...?

When I run htop I have 87 processes (PID 1090 to 1177) of /usr/sbin/console-kit-daemon --no-daemon

Now, truthfully speaking I cannot get ps -ef on all of the processes (I tested a few and I can get it on only one) and gnome-system-monitor does not have a process with the name console-kit-daemon...

Can somebody shed some light on that, please once and for all...

[aquo (sbauch)]

Created an attachment (id=36072)
Patch to make maximal number of watched VTs configurable

I once wrote a small patch for an older ubuntu version that makes it possible to limit the number of watched VTs. The patch is old, for consolekit-0.2.3 and I don't know if it still applies. The main idea was to make the maximal number of threads configurable to the user.

https://bugs.launchpad.net/consolekit/+bug/148454/comments/35

I would like to know if it makes sense to watch Virtual Terminals that have no gettys attached?

[Lennart-poettering (lennart-poettering)]

A few kernel releases back a new kernel API was added that makes the many threads unnecessary. Instead of coming up with ugly work-arounds for the current "problem", please fix things properly and just prepare a patch that ports CK to the new API entirely.

[codeshepherd (codeshepherd)]

my ubuntu server has 63 threads of CKD running.

pstree
init─┬─atd
     ├─avahi-daemon───avahi-daemon
     ├─beanstalkd
     ├─console-kit-dae───63*[{console-kit-dae}]

Is there a way to gracefully exit CKD? I am a bit paranoid about using sudo killall.

[ntucker (ntucker-launchpad)]

I have a server running karmic and I stumbled across this bug via google after noticing that console-kit-daemon is currently using up 1519m virtual and 546m resident memory (according to top). Just a datapoint for those who don't think this sort of bloat is worth tracking down. I'm still unclear on what exactly consolekit even does, especially on a server which never even gets a single console used, let alone 63 of them.

[valus (blaedhorn)]

Since the devs are obviously not even remotely interested in fixing this problem, and I don't have the skills/knowledge to fix it myself, I recompiled the kernel source after editing include/linux/vt.h and reducing 63 (64 ttys) to 11 (12 ttys). At least now console-kit-daemon eats less memory according to the "free" command.

[Kanru Chen (kanru)]

Created an attachment (id=37970)
New patch that uses new VT_WAITEVENT ioctl

New patch that uses new VT_WAITEVENT ioctl.

[Lennart-poettering (lennart-poettering)]

I commited a slightly modified version of Kan-Ru's patch now to git. Thanks!

[Linus Walleij (triad)]

Thanks for fixing this Lennart!

[Lennart-poettering (lennart-poettering)]

(In reply to comment #25)
> Thanks for fixing this Lennart!

Say thanks to Kan-Ru, he did the patch!

[Lennart-poettering (lennart-poettering)]

I have now reverted the patch and reopened this bug. VT_WAITEVENT is inherently racy, since events that happen between the time we return from a VT_WAITEVENT and go back into VT_WAITEVENT are completely lost. That has the effect that when coming back from a suspend sometimes VT switches are not noticed and ACLs incorrectly set up.

Kay has now proposed a new kernel interface that helps us to fix this properly. This is currently in discussion on LKML.

[Lennart-poettering (lennart-poettering)]

The rhbz bug about the race you find here:

https://bugzilla.redhat.com/show_bug.cgi?id=643367

[Kanru Chen (kanru)]

(In reply to comment #27)
> Kay has now proposed a new kernel interface that helps us to fix this properly.
> This is currently in discussion on LKML.

Where could I find the relevant discussions? A quick search using "VT_WAITEVENT" or "ConsoleKit" didn't find anything.

[Lennart-poettering (lennart-poettering)]

See the thread starting with this patch of Kay's:

http://markmail.org/message/dhgzoht63uhfieqc

[Lennart-poettering (lennart-poettering)]

BTW, if somebody cares enough: this bug could be fixed properly now as Kay's patch got merged into .38.

There's now a file "/sys/class/tty/tty0/active" which you can read to get the current VT. And you can poll() for it and will get POLLPRI every time the VT changes.

That said, given that CK is being retired anyway sooner or later (merged into systemd) I do wonder if it is really worth working on this for now.

[Ionut Biru (ionut.biru)]

(In reply to comment #31)
> BTW, if somebody cares enough: this bug could be fixed properly now as Kay's
> patch got merged into .38.
>
> There's now a file "/sys/class/tty/tty0/active" which you can read to get the
> current VT. And you can poll() for it and will get POLLPRI every time the VT
> changes.
>
> That said, given that CK is being retired anyway sooner or later (merged into
> systemd) I do wonder if it is really worth working on this for now.

yes it does. there are other distros out there that doesn't use systemd at all and doesn't have the intention to use it.

[Lennart-poettering (lennart-poettering)]

(In reply to comment #32)
> yes it does. there are other distros out there that doesn't use systemd at all
> and doesn't have the intention to use it.

Are there? If so those folks probably have to become active... We will phase out CK one day, and those folks who find value in sticking with obsolete code will then have come forward and do the work.

[djwiz (djwiz88)]

I didn't understand how we can solve the problem on our system, we have to download a patch? where is the link and how it solve the problem?

the solution is going to be included in a next distribution?

[lVWy2QVhieXLsi (fshmuxibpmsioz)]

Still having this problem in 10.04.2. Dozens of console-kit-daemon processes are spawned rather randomly.

[Dan Kegel (dank)]

See also http://fedoraproject.org/wiki/Features/ckremoval
Supposedly the new Fedora solves the problem by replacing consolekit with systemd.

[A. Denton (aquina)]

See #101 and #128, please. I suggested you to do nothing at all. The memory consumption has nothing to do with the bugs name "console-kit-daemon spawns too many threads" (comment #107, #108, #110, #116) in my opinion. And threads are not "expensive" when it comes to context changes. Also some people here seem not to understand the concept of virtual memory. The developer from freedesktop.org pointed that out AFIR.

My opinion is still: do nothing at all. Neither is it worth the time nor is this bug from 2007-10-03 still an issue. The old UNIX system V init system is not the latest technology and superseded mostly although not exclusively by systemd. Additionally the latest stable kernel version is now 3.9.3 and in Ubuntu 10.04.x LTS its 3.2.0-xx LTS kernel (until 2016) or via LES (EnablementStack) its 3.5.0 and 3.8.0 from quantal and raring respectively.

I do not have the powers to change this bug to WONT FIX state. Someone here at Launchpad either give that permission to me or mark it as such, please.

[Jan Evert van Grootheest (j-e-van-grootheest)]

I think somebody should take a serious look at this. Have a look at this from the c-k-d status:
VmPeak: 2091776 kB
VmSize: 2091744 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 4012 kB
VmRSS: 4012 kB
VmData: 2052720 kB
VmStk: 136 kB
VmExe: 136 kB
VmLib: 5820 kB
VmPTE: 240 kB
VmSwap: 0 kB

So it is using ~2GB for data?! Why does it need 2G?
On a PC with 4G that's half of the memory.

In #128 it was mentioned that consolekit will be merged in systemd. It's been 2 years since. When will it happen?

[Jakob Unterwurzacher (jakobunt)]

No. Look at the actually used RAM:
VmRSS: 4012 kB
4 Megabytes. Oh dear.