registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #14352
[Bug 148454] Re: console-kit-daemon spawns too many threads
Launchpad has imported 26 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=17720.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-09-22T11:42:28+00:00 Alex Riesen wrote:
>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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/51
------------------------------------------------------------------------
On 2008-10-02T04:50:11+00:00 Martin Pitt wrote:
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"?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/53
------------------------------------------------------------------------
On 2008-10-02T04:56:47+00:00 Martin Pitt wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/54
------------------------------------------------------------------------
On 2008-11-14T14:32:09+00:00 Linus Walleij wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/58
------------------------------------------------------------------------
On 2008-11-14T15:59:59+00:00 Alex Riesen wrote:
(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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/59
------------------------------------------------------------------------
On 2009-02-11T15:27:42+00:00 William Jon McCann wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/61
------------------------------------------------------------------------
On 2009-02-11T16:17:12+00:00 Linus Walleij wrote:
Aha it's not a bug it's a feature.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/62
------------------------------------------------------------------------
On 2009-03-24T13:51:25+00:00 micah4 wrote:
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).
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/73
------------------------------------------------------------------------
On 2009-03-24T13:53:40+00:00 micah4 wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/74
------------------------------------------------------------------------
On 2009-04-06T06:52:24+00:00 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 Jon McCann but did not get any
response.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/80
------------------------------------------------------------------------
On 2009-04-24T14:53:24+00:00 Michael Biebl wrote:
(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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/83
------------------------------------------------------------------------
On 2009-06-08T07:25:53+00:00 Matthias Clasen 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 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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/85
------------------------------------------------------------------------
On 2009-07-27T14:46:59+00:00 Lennart-poettering wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/87
------------------------------------------------------------------------
On 2009-09-23T19:29:25+00:00 William Jon McCann wrote:
Lennart, was there any followup from Alan on this?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/88
------------------------------------------------------------------------
On 2009-09-24T08:19:58+00:00 Lennart-poettering wrote:
(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)
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/89
------------------------------------------------------------------------
On 2010-01-28T15:46:55+00:00 William Jon McCann wrote:
Lennart, any chance you can make a patch to use this new functionality?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/102
------------------------------------------------------------------------
On 2010-02-16T02:08:08+00:00 Rez wrote:
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?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/103
------------------------------------------------------------------------
On 2010-02-16T06:25:30+00:00 Lennart-poettering wrote:
(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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/104
------------------------------------------------------------------------
On 2010-02-16T08:01:38+00:00 Rez wrote:
(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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/105
------------------------------------------------------------------------
On 2010-02-16T10:47:32+00:00 Lennart-poettering wrote:
(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?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/106
------------------------------------------------------------------------
On 2010-04-06T00:25:40+00:00 rifter wrote:
(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?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/109
------------------------------------------------------------------------
On 2010-06-05T04:29:41+00:00 aquo wrote:
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?
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/113
------------------------------------------------------------------------
On 2010-06-05T05:41:05+00:00 Lennart-poettering wrote:
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.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/114
------------------------------------------------------------------------
On 2010-08-19T02:38:15+00:00 Kan-Ru Chen wrote:
Created an attachment (id=37970)
New patch that uses new VT_WAITEVENT ioctl
New patch that uses new VT_WAITEVENT ioctl.
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/118
------------------------------------------------------------------------
On 2010-09-06T07:40:31+00:00 Lennart-poettering wrote:
I commited a slightly modified version of Kan-Ru's patch now to git.
Thanks!
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/119
------------------------------------------------------------------------
On 2010-09-10T03:30:28+00:00 Linus Walleij wrote:
Thanks for fixing this Lennart!
Reply at: https://bugs.launchpad.net/consolekit/+bug/148454/comments/120
** Changed in: consolekit
Status: Confirmed => Fix Released
** Changed in: consolekit
Importance: Unknown => Medium
--
console-kit-daemon spawns too many threads
https://bugs.launchpad.net/bugs/148454
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Fedora.
