https://bugs.exim.org/show_bug.cgi?id=813
Sven Ludwig <exim-bugs@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |exim-bugs@???
--- Comment #3 from Sven Ludwig <exim-bugs@???> ---
I fall over this limit in the last week. The problem here is that this limit
isn't documented. You find it only if you google for "exim 4096" and you end up
in the original post about this issue. There is no hint in the exim
documentation.
So even if you wont raise the limit or make it compile time configurable you
should add a hint to the documentation about that fact.
On the overhand there is a way of bypassing this issue by setting
smtp_accept_max to zero, which disables the connection accounting within exim.
So you can get beyond this 4096 limitation.
In order to have a proper connection accounting in this scenario you would have
to implement it using ACL logic and an external data storage like memcached or
redis to hold this number accessible for all instances(forks) of exim.
acl_smtp_connect = acl_check_connect
acl_smtp_quit = acl_check_term
acl_smtp_notquit = acl_check_term
begin acl
acl_check_connect:
warn # do crazy increment
acl_check_term:
warn # do crazy decrement
But there are several pit falls and raise condition in this approach, which are
not easy to handle within the exim acl context.
> With one process per connection, this is not a wise idea given Exim's current design.
Considering first you do not want to increase the number of pids available you
have 32768 free for use. (/proc/sys/kernel/pid_max)
Considering that we have a fixed limitation of 32768-<other processes>
concurrent connections. According to the data structure used in daemon.c it
might be possible to raise this a bit.
typedef struct smtp_slot {
pid_t pid; /* pid of the spawned reception process */
uschar *host_address; /* address of the client host */
} smtp_slot;
This is the data structure which keeps the data as an array. 32 bits (pid) +
128 bits (max host address with \0).
With the current hard limit this thing can grow up to 81920 bytes.
If it would be increased to be 65536(will not be reached) it can grow up to
655360 bytes(10 times bigger than before), which isn't that big deal anymore.
Never the less that not enough free pids would be available to fork anyways. As
far as i red through the source of daemon.c the problem of forks, which do not
work out, is handled already.
What I see as limit here is to use 'sysconf(_SC_CHILD_MAX)' {unistd.h} instead
of 4096 which would return the exact number of processes we can wait to be
finished with the following line:
while ((pid = waitpid(-1, &status, WNOHANG)) > 0)
Even if this is issue is in wont-fix state, i'd like you to share your thoughts
about it :)
--
You are receiving this mail because:
You are on the CC list for the bug.
