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.

[Nick Demou (ndemou)]

Lynoure & Stefan, please take the time to explain to us what the problem with console-kit-deamon is, because until now everybody else HAS NOT (and it doesn't help that originally some of the posters were chasing a completely different problem that wasn't even there). That's the reason I've marked this report as invalid: because it doesn't define what the problem is with enough clarity.

Now I'll have to make some guesses regarding the problem you see and ask you for some clarification:

Lynoure,
you seem to suggest that spawning 60 threads is a problem but WHY? People have posted a similar view before you but everybody has backed this up with either vague complains about wasted "system resources" in general or wrong[1] complains about wasted memory in particular. If you know better than the previous posters please take the time to make it clear to the guy that will have to deal with this bug.

Stefan,
you write like you know what CKD does with the threads it's spawning and how many of them it's using and how many of them are wasted but you could very well be guessing (I'm sorry but life is hard and I swear you wouldn't be the first person I found posting wild guesses in launchpad). If you do know enough then please take the time to elaborate just a little bit to help the developers since you are asking for them to help you also.

_______________________
[1] hint: most of the day if you get the %MEM column that htop reports about all the threads thunderbird and firefox have spawned and add it up you get more than 200 to 300% -- at the same time my swap partition is sleeping like a baby.

[Lynoure Braakman (lynoure)]

Mr. Demou, I don't have any more knowledge on this than any other reporter, or you. I don't mind at all if the report gets closed with an explanation on why this is a feature, not a bug. Actually that would be a great thing as it would leave a findable explanation for people who in the future wonder about the huge number of threads.

If a bug report does not define what the problem is with enough clarity, they are normally just plain "incomplete". I'm pretty sure the Low priority on this will keep any developer from wasting their time on this if it is not something worth changing.

[Nick Demou (ndemou)]

Lynoure, I understand your questions and desire for explanations and that's why I've created a question from this bug

regarding:
> If a bug report does not define what the problem is with enough clarity, they are normally just plain "incomplete".

...from my point of view and after reading help.launchpad.net/BugStatuses, invalid is more suitable:

   Invalid: the report describes the software's normal behaviour, or is unsuitable for any other reason.

I'm just waiting to hear from Stefan because I might have got him wrong

[Vladimir (snape)]

Nick,

if you don't understand what is the problem, maybe you should go work for Microsoft. They have same philosophy: Wasted resources? So what? Go buy better machine. We don't care.

So this the problem. Linux used to be synonym for "small, efficient". Thanks to people like yourself it is no longer true. Linux became monster just like Windows.

[Nick Demou (ndemou)]

Vladimir, our difference is not whether I care about wasted resources (I do) but whether I see any worthy evidence of wasted resources (I don't). But I'm afraid that at this point of time you probably wouldn't believe me if I told you that the sky is blue so I had to google for a few minutes in order to show you some quotes you may wish to examine before blaming those 60 sleeping threads for your crawling linux system. They are from IBM's developer works and from Linux Journal and you will find them just after the next paragraph.

Before the data a sincere advice with no empathy whatsoever: an attitude of "come on you incapable programmers -- fix those obvious mistakes in your code" when coupled with vague and disorientated complains about stuff you hardly understand DOESN'T help. Note that I don't pretend to know everything about life, universe and CDK -- I just don't call the developers of CDK incapable until I have some pretty good idea about what's going wrong with their program.

POSIX threads explained -- http://www.ibm.com/developerworks/library/l-posix1.html
<<<
Threads also happen to be extremely nimble. [...] Because of this, you can use a whole bunch of threads and not worry too much about the CPU and memory overhead incurred. You don't have a big CPU hit the way you do with fork().

This means you can generally create threads whenever it makes sense in your program.
>>>

The Linux Process Model -- http://www.linuxjournal.com/article/3814
<<<
threads share the same address space completely. All the threads run in the same address space, so a context switch is basically just a jump from one code location to another
>>>

So: those 60 threads use the same memory as one thread would. Regarding the CPU use ps (with -H of course) and note how they don't use any CPU at all. As for the available threads: we have about 32.000 to spare so again check with ps to see if you are even remotely close to using them all (I've never seen more that 2000 threads and that was on a really heavily loaded web/db/mail server).

[Remove Me (remove-me)]

It still reserves some stack (65k?), causes unnecessary context switches and takes some attention of the scheduler.
It's still bloat to request a resource which is NEVER used (a thread to monitor console 58? What for?!).

And BTW, why is FreeBSD configured to the number of active consoles?
Could it be because someone was a bit clueless regarding Linux or just lazy?
Lets look at sysfs, /sys/class/vc. It lists allocated kernel consoles:

$ ll /sys/class/vc
total 0
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs1
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs2
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs3
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs4
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs5
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs6
drwxr-xr-x 3 root root 0 2008-07-10 21:39 vcs7
...

You can even monitor changes to the directory (with inotify).
Patch attached (without inotify).

[Vladimir (snape)]

Alex, thanks for your patch. But how do we implement it? A little description would certainly help.

[Remove Me (remove-me)]

How does who implement what? Inotify? Detection of sysfs mounted? BSD?

[Remove Me (remove-me)]

Sadly, the patch blocks shutdown and restart through hal (at least that's how I interpreted the errors).
So DON'T USE IT.

Actually, that's kind of mistery to me: how can it block the shutdown?

[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.

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

By now, everybody should have come to the conclusion that there is in fact nobody here who actually has the required know-how CKD to figure out of what's going on here; all we have are 2 possibly broken patches and plenty of vague assumptions.

I still say: if you're really that concerned, you should file a bug in the freedesktop bug tracker: https://bugs.freedesktop.org

[Remove Me (remove-me)]

From Ubuntu: https://bugs.launchpad.net/bugs/148454

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.

[Remove Me (remove-me)]

Right.

https://bugs.freedesktop.org/show_bug.cgi?id=17720

[Martin Pitt (pitti)]

This might also explain https://launchpad.net/bugs/184519, which has 26 duplicates already, with this stack trace:

  http://launchpadlibrarian.net/12890099/Stacktrace.txt

(crash in vt_thread_start). Or was that actually fixed by dfcab49480565a7bcf71752c5b39eb367df81a19 "cleanly shutdown event logging threads"?

[Martin Pitt (pitti)]

Ah, to answer myself, this is probably the case: https://launchpad.net/bugs/196724 is another set of 50 duplicates about the same "crash in thread start" problem, which was fixed with the 0.3 patch I mentioned.

[ironstorm (ironstorm-gmail)]

WTF is this consoleKit thing for, why the heck does it need 60 dormant threads, and why do 50 odd packages depend on it?

http://people.freedesktop.org/~mccann/doc/ConsoleKit/ConsoleKit.html#id2565344 -- that's helpful!

Seriously, I've been using RedHat 5.2 and have never had need of whatever fast-user-switching or seat counting this thing provides...

If it can't get its thread count under control I'd just as soon uninstall it, it seems however just about everything on the desktop depends on it for something though.

[ironstorm (ironstorm-gmail)]

>> Seriously, I've been using RedHat 5.2 and have never had need of whatever fast-user-switching or seat counting this thing provides...

clearly I'm up way past my bed time too... that should read using Linux since RH5.2... haha

[Loye Young (loyeyoung)]

@IronStorm
>everything on the desktop
>depends on it for something

<off-topic rant>

Yet another example of rampant dependency inflation. I've complained
about this before in a variety of contexts. Somehow, the entire open
source developer community needs to get a handle on it. It's a big
problem for IYCC, and I suspect other OEMs, when trying to tailor a
machine for a particular use case or market.

The Debian Policy Manual has a a very good statement on how to
categorize dependencies.
http://www.debian.org/doc/debian-policy/ch-relationships.html
Unfortunately, the policy seems not to be enforced nearly enough.

In particular, the entire community should make greater use of
Suggests, Enhances, and Recommends dependencies, of virtual packages
that "Provide" packages, and of meta-packages that are similarly
careful about dependency relationships.

Dependency inflation isn't restricted to Ubuntu. Best I can tell, all
the distros are guilty of it, including RedHat. :-) We're working on
weeding it out of the IYCC Distribution, but it's not a trivial task
because of the pervasiveness of the problem.

I'm not sure how to create a process that would herd the cats, but
it's what's needed. Perhaps each distro should have a Dependency Czar
to review dependencies and crackdown on ever-expanding dependencies.

</off-topic rant>

Happy Trails,

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

[Linus Walleij (triad)]

I experience these 63 spawned processes as well, if for nothing else
(all CoW memory etc accounted for) it hogs the scheduler by making
it slower to sort the CFS RB-tree which is O(log n).

An Ubuntu user proposed the following patch to
autoconfigure the maximum number of consoles from sysfs:

http://launchpadlibrarian.net/15940846/0001-Autoconfigure-maximum-number-of-kernel-consoles.patch

which looks sane to me.

I made a graphical tool to display process migration etc in the system
and the plethora of console-kit-daemons really cloud the view.

[Remove Me (remove-me)]

(In reply to comment #3)
> I experience these 63 spawned processes as well, if for nothing else
> (all CoW memory etc accounted for) it hogs the scheduler by making
> it slower to sort the CFS RB-tree which is O(log n).
>
> An Ubuntu user proposed the following patch to
> autoconfigure the maximum number of consoles from sysfs:
>
> http://launchpadlibrarian.net/15940846/0001-Autoconfigure-maximum-number-of-kernel-consoles.patch
>
> which looks sane to me.
>
> I made a graphical tool to display process migration etc in the system
> and the plethora of console-kit-daemons really cloud the view.
>

I am that user. The patch broke the logout process of Ubuntu: the
currently logged in user lost the ability to power off the system,
only logout worked.

[Jakob Unterwurzacher (jakobunt)]

> If it can't get its thread count under control I'd just as soon uninstall it,
> it seems however just about everything on the desktop depends on it for something though.

On my system, console-kit-daemon with all its threads takes about 2MB of RAM (RSS in ps aux).

This has near *zero* impact on *any* modern (>64MB RAM) PC.

Do not uninstall it - this will break a lot of things and will gain you *nothing*.

The bug should still be fixed, though, as these thread are unneccessary (but harmless).

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

Sorry for the long delay. However, it seems like this bug has a few different issues in it. The issue that is reported in the initial report is actually not a bug but a design decision. Once we improve or replace the VT subsystem we can do better than this. Until then we don't have another way.

[Linus Walleij (triad)]

Aha it's not a bug it's a feature.

[Vladimir (snape)]

After seeing that the discussion goes nowhere and nobody in charge is willing to do anything about this problem, I chose my own solution. It is ugly, dirty, but it works for now.

I wrote in C program with only one instruction: exit. I have replaced the huge console-kit-daemon in /usr/sbin with this "program" and bingo. It works. No more 60+ threads. And the funny stuff is here: System seems to work just as before. In other words IT DOES NOT NEED FOR THIS MONSTER. Console kit daemon is completely useless utility.

For those of you, who want to "solve" this problem I am attaching here my console-kit-daemon utility. Please keep in mind this is only temporary solution and it is far from perfect.

[mehturt (mehturt)]

Why not using:
#!/bin/sh
exit 0

[Loye Young (loyeyoung)]

Rock on, Vlad!

I'd like to take a look at your utility. It may be of use in other cases.
Would you post the source code, or a link to where the code may be found?

Thanks.

Loye Young

On Tue, Feb 24, 2009 at 3:47 PM, Vladimir wrote:

> After seeing that the discussion goes nowhere and nobody in charge is
> willing to do anything about this problem, I chose my own solution. It
> is ugly, dirty, but it works for now.
>
> I wrote in C program with only one instruction: exit. I have replaced
> the huge console-kit-daemon in /usr/sbin with this "program" and bingo.
> It works. No more 60+ threads. And the funny stuff is here: System seems
> to work just as before. In other words IT DOES NOT NEED FOR THIS
> MONSTER. Console kit daemon is completely useless utility.
>
> For those of you, who want to "solve" this problem I am attaching here
> my console-kit-daemon utility. Please keep in mind this is only
> temporary solution and it is far from perfect.
>
>
>

[Jakob Unterwurzacher (jakobunt)]

@Vladimir:
Now what? Is your system more responsive? Do you have significantly more free RAM? Do you get 2FPS more in some benchmark?
What is the BENEFIT?

[Vladimir (snape)]

2 mehthurt
Yes, even better. :-)

2 Loye Young (source enclosed)
The source:
   /* console-kit-daemon */
     int main() {
     return 0;
     }
  /* console-kit-daemon END*/
Cut and paste into file console-kit-daemon.c and do the following:
    gcc -Wall -o console-kit-daemon console-kit-daemon.c

2 Jakob Unterwurzacher
This is a wrong question. The question should be like this: If there is a utility with questionable benefits eating up unnecessary resources and doing next to nothing, then why we should keep it there?

If we accept the fact, that "it does not matter" we could quickly find ourself literally buried under pile of similar garbage. Linux used to be *small and efficient*. Please try keep it that way.

[Loye Young (loyeyoung)]

Vladamir is exactly right. Kruft needs to stay off our systems.

Besides, Microsoft and Macrovision have patents on bloatware, and they would
be pissed if we infringed on their intellectual property.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://archive.iycc.net

On Wed, Feb 25, 2009 at 8:55 AM, Vladimir <email address hidden> wrote:

> Jakob Unterwurzacher
> This is a wrong question. The question should be like this: If there is a
> utility with questionable benefits eating up unnecessary resources and doing
> next to nothing, then why we should keep it there?
>
> If we accept the fact, that "it does not matter" we could quickly find
> ourself literally buried under pile of similar garbage. Linux used to
> be *small and efficient*. Please try keep it that way.
>
>

[Whit Blauvelt (whit-launchpad)]

On an Xubuntu Intrepid server, just found console-kit-daemon taking 96-100% of CPU. Yes, this is not the same bug as this report is. But it does seem like including this package in a default install is bad engineering.

[micah4 (atomicsuntan)]

60 useless threads may not use much more memory or consume much more cpu on a modern machine. They do, however, use a significant portion of my resources.

They consume almost 30% of my listing when I run ps -eLf and nearly 50% of my listing when I run pstree -p. They consume keystrokes when I have to add "| grep -v console-kit" to any process listing command I run to get an output that is digestible. And no, "use a pager" isn't an acceptable answer when I want to see a snapshot of what my system is running on one screen, which I can actually do if there aren't 60 threads fobbing up the listing.

Yes, we generally have more CPU cycles and memory than we need most of the time, but screen real estate is still in short supply, as is people's tolerance for obnoxious things.

Even if the console kit is operating properly and is actually designed to spawn this many threads, it immediately looks like a problem and people wonder what's wrong and whether it should be that way. There's no point in people wasting their time trying to figure out if this application is broken or gone haywire- especially when the application doesn't really need 60 threads.

Whether you think it's a "real problem" or not, it is annoying to a lot of people, myself included, and that makes it a real problem. There is no reason this application should need to spawn 60 threads- if they're mostly idle and not really using resources then that just makes it *especially* true that we shouldn't need so many of them. Maybe it was a convenient hack to get the application released quickly, but it shouldn't be difficult (for somebody who understands the code) to change it to run without ridiculous numbers of threads.

[micah4 (atomicsuntan)]

A quick look at the code shows that the threads are created so that they can sleep on an ioctl to the virtual consoles, with one thread for each (possible) virtual console which waits for the VC to become active. The threads were probably created so that the application could be released without requiring a patch to the kernel. Note that this application does not need 60 threads on Solaris, which provides asynchronous notification of VC switching via SIGPOLL. A similar method could be achieved with a very small kernel patch to allow VT_WAITACTIVE to return whenever any VC switch occurs, e.g., by waiting on a magic console number or adding a new ioctl command which provides that behavior. In fact the kernel already wakes everybody up whenever a VC switch occurs, it just puts them back to sleep unless they are waiting on the specific vc that was requested- which is why there has to be one requesting thread for each possible vc. So it would be a very minor change but it would be a kernel change.

[Jakob Unterwurzacher (jakobunt)]

@micah4:
This is also what the Red Hat bugtracker ( https://bugzilla.redhat.com/show_bug.cgi?id=457845 ) says:

Comment #1 From Matthias Clasen 2008-08-05 18:28:43 EDT -------
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.

[micah4 (atomicsuntan)]

Created an attachment (id=24210)
Patch to console kit to use alternative wait mechanism

Here is a patch for console kit that removes the numerous threads by utilizing a new kernel ioctl. (This requires a kernel patch as well).

[micah4 (atomicsuntan)]

Created an attachment (id=24211)
Kernel patch adds a VT_WAITSWITCH ioctl command

This patch adds an ioctl to the kernel which console-kit can use to wait on a terminal switch without creating 60 threads. It's not incredibly pretty but it seems to work and demonstrates a straightforward solution.

[micah4 (atomicsuntan)]

Here is a patch, one for ConsoleKit and one for the kernel that will get rid of the numerous threads. Adds a new ioctl to the VT system. It's kludgy, but it is a straightforward solution which works AFAICT (though I don't really know how to test whether console-kit-daemon is working properly).

[micah4 (atomicsuntan)]

Here is the patch for the kernel.

[micah4 (atomicsuntan)]

Sorry, last kernel patch missed an include file. Use this patch instead.

[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).

[James Westby (james-w)]

Hi micah,

Thanks for working on this. I would recommend that you first try
and get your kernel patch included in Linus' tree. Once that is available
we can work on including your patch in to consolekit.

I'm not at all well placed to review the kernel patch, so taking it to
the kernel developers will be a much better use of your time.

Thanks,

James

[Nick Demou (ndemou)]

Thanks very much micah4. Both for broadening my view on what is a bug and for your analysis and patch. I would be very much pleased if you push your patch either directly to the kernel developers or through the ConsoleKit maintainer. Hope you have the time.
(PS: I believe a lot more people feel the same.)

[micah4 (atomicsuntan)]

Does anybody know who the official maintainer of this package is? I am willing to work on getting the patch included in the kernel if this approach is acceptable to the ConsoleKit team, but I don't want to bother with the kernel side of things unless ConsoleKit will incorporate the changes also. I tried emailing Jon McCann but did not get any response.

[micah4 (atomicsuntan)]

Does anybody know who the official maintainer of this package is? I am willing to work on getting the patch included in the kernel if this approach is acceptable to the ConsoleKit team, but I don't want to bother with the kernel side of things unless ConsoleKit will incorporate the changes also. I tried emailing John McCann but got no response.

[James Westby (james-w)]

On Mon, 2009-04-06 at 13:50 +0000, micah4 wrote:
> Does anybody know who the official maintainer of this package is? I am
> willing to work on getting the patch included in the kernel if this
> approach is acceptable to the ConsoleKit team, but I don't want to
> bother with the kernel side of things unless ConsoleKit will incorporate
> the changes also. I tried emailing John McCann but got no response.

McCann is the maintainer, so he's the one to talk to.

I presume that he wouldn't have a problem integrating a patch to do
this. I imagine the kernel changes will be more involved.

Thanks,

James

[Michael Biebl (mbiebl)]

(In reply to comment #9)
> Does anybody know who the official maintainer of this package is? I am willing

William Jon McCann is the official maintainer.

> to work on getting the patch included in the kernel if this approach is
> acceptable to the ConsoleKit team, but I don't want to bother with the kernel
> side of things unless ConsoleKit will incorporate the changes also. I tried
> emailing Jon McCann but did not get any response.
>

That's very unfortunate. I can only assume he is very busy. Maybe it helps to ping him again.

[hikaricore (hikaricore)]

So a year and a half later this is still a problem... what gives?

[Matthias Clasen (mclasen)]

> Does anybody know who the official maintainer of this package is? I am willing
> to work on getting the patch included in the kernel if this approach is
> acceptable to the ConsoleKit team, but I don't want to bother with the kernel
> side of things unless ConsoleKit will incorporate the changes also. I tried
> emailing Jon McCann but did not get any response.

This kind of hedging typically doesn't work were well in free software projects.
Don't let the lack of preapproval here keep you from getting the kernel side of things fixed.

[James Westby (james-w)]

http://lkml.org/lkml/2009/6/29/487

[Lennart-poettering (lennart-poettering)]

BTW:

http://lkml.indiana.edu/hypermail/linux/kernel/0906.3/02726.html

Alan wanted cook up his own patch, but uh, he didn't respond in a week or so.

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

Lennart, was there any followup from Alan on this?

[Lennart-poettering (lennart-poettering)]

(In reply to comment #13)
> Lennart, was there any followup from Alan on this?
>

Alan gave up maintainership of the console stuff a few weeks back. gregkh then took this up and one of the first things he did is merge Alan's patch into his tree. Two days ago this was then merged into mainline. So I guess that means the kernel infrstructure should now be able to cut down the threads to two (the ioctl is still blocking)

[hikaricore (hikaricore)]

And it's still in Karmic.

Look I know this isn't a huge deal but it's a pain in the ass for process management.
There is a fix for it and I'd love to see it applied in my lifetime.

[syntag (lotekware)]

From http://www.kernelpodcast.org/2009/07/04/20090702-linux-kernel-podcast/

"...Alan Cox followed up to Lennart Poettering’s previous VT_WAITACTIVE patch with a more generic event interface for Virtual Terminals..." (july 2, 2009)

Is he talking about the same patch? Then perhaps this patch IS in the new kernels but console-kit has yet to be patched?

I really hope someone solves this problem once and for all...

[Linuxonlinehelp_de (linuxhelp)]

Hello at ALL,

do anyone knows a solution for ubuntu 9.04?

i know this strange bug does debian lenny not have..

on older Laptop with up to 512MB Ram it brakes out the performance

and there is no possibilty to install xserver-xorg by default without hal+dbus+consolekit to

use older office used Laptops with icewm or jwm

i can't setup classroom PCs with ubuntu if there is no solution..

regards Tom
www.linuxonlinehelp.de

[Topher (topher-redhat-bugs)]

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

[syntag (lotekware)]

still no updates?

one month ago Lennart Poettering wrote (2009-09-24 08:19:58 PST): "Alan gave up maintainership of the console stuff a few weeks back. gregkh then took this up and one of the first things he did is merge Alan's patch into his tree. Two days ago this was then merged into mainline. So I guess that means the kernel infrstructure should now be able to cut down the threads to two (the ioctl is still blocking)"

[hikaricore (hikaricore)]

2 years later still not fixed... really? this isn't gnome-screensaver we're talking about people.. :p

[Felix (apoapo)]

console-kit-dae───63*[{console-kit-dae}]

9.1 karmic

[Barn (barnsk2000)]

I know, hikaricore...
I don't understand the 'forget it' attitude. As has been pointed out, Linux has always been built efficiently, just because a particular inefficiency 'isn't very inefficient' why should we ignore it? It still exists.
What's MORE worrying is the number of people posting who have NO curiosity or desire for 'elegance' at all...they're not (whatever they claim) Engineers....

[Jakob Unterwurzacher (jakobunt)]

No one says that this should be ignored. I argue that people should stop proposing crazy workarounds that may break your entire system (now or at the next distro upgrade) for little benefit.

Upstream has not fixed this, that's why it's not fixed in Ubuntu ( see http://bugs.freedesktop.org/show_bug.cgi?id=17720 ).

[Carl Fink (carl-finknetwork)]

Whoever is responsible, the fact that there are so MANY pointless, unfixed problems is an indictment of Free Software in general. (Absurd overthreading, htop's unclear mixing of userland threads with processes, hundreds of packages depending on consolekit for no particular reason, consolekit being rolled out in major Linux distros before it's actually fully functional.)

[Nick Demou (ndemou)]

Carl Fink wrote:
> the fact that there are so MANY pointless, unfixed problems is an indictment of Free Software in general

actually, in general, it's how almost all software is build. It's just that with Free Software it's easier to know when it happens because the hood is open.

And even more generally that is how humans act when fixing appears to be less costly than designing. And it's actually A Good Thing when fixing is indeed less costly than designing.

[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.