On Mon, 18 Nov 2013 12:52:26 -0500
Eric Covener wrote:
>
> # Set the maximum number of file descriptors allowed per child
> process. if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
> $ULIMIT_MAX_FILES
> fi
>
>
> Should we do the same for threads/processes? I was going to propose
> this for some k
current apachectl:
#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES="ulimit -S -n `ulimit
>
> IMHO this explains it as limits.conf is a configuration file for PAM. If you
> don't use
> any PAM methods (haven't worked out which would be needed) in the code the
> limits will not
> be applied after setuid. Of course pam_limits.so need to be configured for
> session for your app
> as wel
Eric Covener wrote:
> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem wrote:
>>
>>
>> Eric Covener wrote:
>>> I was looking at a typical apr_thread_create failure for creating a
>>> large # of threads on a system, and the only solution was to increase
>>> roots RLIMIT_NPROC as opposed to the (h
On Tue, Nov 12, 2013 at 1:16 PM, William A. Rowe Jr.
wrote:
> On Tue, 12 Nov 2013 09:04:13 -0500
> Eric Covener wrote:
>
>> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem
>> wrote:
>> >
>> >
>> > Eric Covener wrote:
>> >> I was looking at a typical apr_thread_create failure for creating a
>> >>
On Tue, 12 Nov 2013 09:04:13 -0500
Eric Covener wrote:
> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem
> wrote:
> >
> >
> > Eric Covener wrote:
> >> I was looking at a typical apr_thread_create failure for creating a
> >> large # of threads on a system, and the only solution was to
> >> increa
On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem wrote:
>
>
> Eric Covener wrote:
>> I was looking at a typical apr_thread_create failure for creating a
>> large # of threads on a system, and the only solution was to increase
>> roots RLIMIT_NPROC as opposed to the (httpd.conf configured) "User"
>
Eric Covener wrote:
> I was looking at a typical apr_thread_create failure for creating a
> large # of threads on a system, and the only solution was to increase
> roots RLIMIT_NPROC as opposed to the (httpd.conf configured) "User"
> limits
I assume that you configured that via /etc/security/li
See also PR#55763 -- root has a soft limit of 1024 ulimit -u on RHEL6.
On Sat, Nov 9, 2013 at 7:46 AM, Eric Covener wrote:
> Behavior seems to be that after the setuid, we don't get the new users
> limits -- we just get a one-time check to make sure our currently
> single-thread process won't pu
Behavior seems to be that after the setuid, we don't get the new users
limits -- we just get a one-time check to make sure our currently
single-thread process won't push us over the new users' limit.
Confirmed in /proc/$pid/limits on a child in start_threads() that
roots limit is in place.
On Sat,
I was looking at a typical apr_thread_create failure for creating a
large # of threads on a system, and the only solution was to increase
roots RLIMIT_NPROC as opposed to the (httpd.conf configured) "User"
limits
But every manpage I read says that after the setuid(), we should have
the new users
11 matches
Mail list logo