** Changed in: ltsp (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/381063
Title:
dbus needs more than the default 1024 open files
To manage notifications about
This should be fixed by 1.4.6 according to upstream NEWS.
dbus (1.4.6-1ubuntu1) natty; urgency=low
* Merge with Debian unstable. Remaining Ubuntu changes:
- Install into / rather than /usr.
- debian/dbus.postinst: Use upstart call instead of invoking the init.d
script for checki
** Description changed:
+ === PROBLEM ===
+ On a multiuser system with many desktop users, the system dbus-daemon process
can easily exceed the 1024 open files allowed by the default ulimit. When it
exceeds that, it goes into a tight loop, sucking up 100% processor, and nobody
can log in.
+
+
Hrrm. In my case that seems to be the session bus not the system bus, so
it might not be related (it looks like its leaking fd's somewhere
because during normal usage it just has 110fds open), new bug or similar
enough?
--
dbus needs more than the default 1024 open files
https://bugs.launchpad.ne
Thats a current lucid of today with dbus 1.2.16-2ubuntu2.
** Attachment added: "dbus-1025-fd-strace.txt"
http://launchpadlibrarian.net/37564404/dbus-1025-fd-strace.txt
--
dbus needs more than the default 1024 open files
https://bugs.launchpad.net/bugs/381063
You received this bug notification
I just hit the same problem. Unfortunately in a single user environment,
but thats likely a separate issue...
Backtrace and strace attached.
** Attachment added: "dbus-1025-fd-gdb-bt.txt"
http://launchpadlibrarian.net/37564303/dbus-1025-fd-gdb-bt.txt
--
dbus needs more than the default 1024
On Tue, 2009-09-08 at 18:36 +, Steve Bergman wrote:
> And one more thing. Note that I had my problem solved before I ever
> opened this ticket. I opened it, as a courtesy, to report the problem,
> give some insight as to things that made it particularly difficult to
> track down, and get the w
And one more thing. Note that I had my problem solved before I ever
opened this ticket. I opened it, as a courtesy, to report the problem,
give some insight as to things that made it particularly difficult to
track down, and get the workaround published so that others might not
have quite so much d
Well, let me ask you this. Is there someplace where my customers can
take out an official Canonical support contract that would be sufficient
to persuade Canonical support employees to get off their butts and
actually do some troubleshooting instead of looking for any way they can
to put it all bac
On Tue, 2009-09-08 at 15:53 +, Steve Bergman wrote:
> I'm sorry you feel that way, but I've already done all I can reasonably
> do without doing a disservice to my customer. And if Canonical does not
> understand that, then perhaps Ubuntu doesn't belong in the enterprise.
>
> All things cons
What I can do, when my work load permits, is bring up 60+ vncserver
sessions on a test server. Or, really, I supposed anyone else who cares
could do it if they get to it first. I suspect that this is going to be
quite reproduceable. It's not some hard to reproduce problem that only
the bug reporter
I'm sorry you feel that way, but I've already done all I can reasonably
do without doing a disservice to my customer. And if Canonical does not
understand that, then perhaps Ubuntu doesn't belong in the enterprise.
All things considered, RHEL support subscriptions cost a lot less than
this experi
On Thu, 2009-09-03 at 19:55 +, Jean-Michel Dault wrote:
> We have the same problem too:
>
Were you able to obtain a backtrace from gdb?
Scott
--
Scott James Remnant
sc...@canonical.com
--
dbus needs more than the default 1024 open files
https://bugs.launchpad.net/bugs/381063
You received
On Thu, 2009-09-03 at 20:16 +, Steve Bergman wrote:
> James, with all due respect that is absolutely out of the question. I
> have 70 business users with stable desktops now that "ulimit -n" is set
> to an appropriate value. You are asking me to essentially crash 70 users
> in three cities, an
As an admin, the worst part of this issue was the fact that things would
randomly stop working and lock up. Logins would inexplicably fail. All
with no particular pattern, getting worse and worse... and yet the cause
was not at all obvious. Nothing in daemon.log. Nothing in syslog.
Nothing in messa
The /etc/default/dbus is a great way to fix the problem. It's also
configurable.
I suggest the following patch in the dbus package:
--- /etc/default/dbus.orig 2009-09-03 17:19:14.747613907 -0400
+++ /etc/default/dbus 2009-09-03 16:22:09.117573599 -0400
@@ -8,3 +8,8 @@
# Parameters to pass to
As a workaround, one can add this line to /etc/default/dbus :
ulimit -n 65535
--
dbus needs more than the default 1024 open files
https://bugs.launchpad.net/bugs/381063
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mai
** Changed in: dbus (Ubuntu)
Status: Incomplete => New
--
dbus needs more than the default 1024 open files
https://bugs.launchpad.net/bugs/381063
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-
James, with all due respect that is absolutely out of the question. I
have 70 business users with stable desktops now that "ulimit -n" is set
to an appropriate value. You are asking me to essentially crash 70 users
in three cities, and then clean up all the domino effect problems, like
residual evo
We have the same problem too:
r...@slxats2:~# ps -u messagebus
PID TTY TIME CMD
2677 ?02:28:11 dbus-daemon
r...@slxats2:~# ls /proc/2677/fd|wc -l
1024
r...@slxats2:~#
r...@slxats2:~# (strace -p 2677 2>&1 1>&3 | grep "Too many open files"
1>&2) 3>&1
accept(3, 0xbf8ec168, [16]
I need confirmation of the "tight loop" - could you cause this and run
strace on the dbus-daemon to capture what it's doing.
Ideally also run "gdb" on it and use "bt" to obtain a backtrace
** Changed in: dbus (Ubuntu)
Importance: Undecided => Medium
** Changed in: dbus (Ubuntu)
Status:
21 matches
Mail list logo
