+++ This bug was initially created as a clone of Bug #23194 +++
On that bug, Colin wrote:
I agree that the poll() code here is busted, however I think there's also a
larger issue, which is the desynchronization between the process ulimit for the
bus, and its configuration.
Many Linux forks and embeds use 1024 as a per-process default I believe.
However the default bus configuration we ship has:
parser->limits.max_completed_connections = 2048;
In addition to:
parser->limits.max_incomplete_connections = 64;
For completeness there is also:
parser->limits.max_connections_per_user = 256;
* Should the system bus instance e.g. ask for more via setrlimit() on startup?
We'd have to do this before we called setuid(), since on Linux we need
* Should we change the hardcoded defaults here to be below 1024?
Created attachment 42779 [details] [review]
raise fd limit
Review of attachment 42779 [details] [review]:
Looks promising, some minor things.
@@ +43,3 @@
Is this universal on all Unixes, even rubbish ones? I'd prefer it conditionalized with #ifdef HAVE_SYS_RESOURCE_H (for which you need to add it to an existing AC_CHECK_HEADERS, or add a new one).
@@ +407,3 @@
+ /* Ignore "maximum limit", assume we have the "superuser"
+ * privileges. On Linux this is CAP_SYS_RESOURCE.
Might be worth clarifying this comment to say that yes, we're ignoring errors, and that's deliberate.
Fixed both things, thanks!
Author: Colin Walters <firstname.lastname@example.org>
Date: Mon Jan 31 15:22:14 2011 -0500
bus: Raise file descriptor limit to match configuration
The default configuration has hardcoded 2048 complete connections,
and 64 incomplete. We need at least that number of file descriptors,
plus some for internal use.
In the bus, attempt to call setrlimit() before we drop privileges.
Practically speaking for this means the system bus gets it, the
session bus doesn't.
Reviewed-By: Simon McVittie <email@example.com>