great! thank you very much. can someone put all the pieces togther to one
new peruser patch release? (including pam patch). i am more an admin than a
developer, so please help me.

if the new release work like it should, i can documentate it and build
packages for debian and ubuntu. possibly i can also create rpm packages as
well.

On Wed, 11 Mar 2009 15:33:07 +0200, Janno Sannik <[email protected]> wrote:
> This doesn't include the pam_limits patch, but we sure are interested in 
> that, so I might check it out also since this popped up again.
> The post was something like this :
> 
> ***
> Greetings From DataCode Team!
> 
> This our update patch for peruser 0.3.0. Praise and criticism is welcome.
> 
> Features it provides:
> * Multiplexer pool: Multiplexer are spawned automatically if more of 
> them are needed. No need to
> specify duplicate Multiplexer configuration lines anymore. If you do 
> that, then apache starts with
> more multiplexers, but maintenance will clean them up in a while.
> 
> Configuration variables:
> MinMultiplexers 3 #minimum amount of multiplexer that will be kept
> alive. Defaults to 3 if unset.
> MaxMultiplexers 20 #maximum amount of multiplexer that will be allowed
> to spawn. Defaults to 20 if unset.
> 
> 
> * Multiplexer now checks if the processor has any available children and 
> will try to wait for it, if
> it doesn't. If the multiplexer is not able to pass the request within 
> given time then the request
> will be dropped. With each failed pass, the multiplexer will wait less 
> time (and eventually it won't
> wait at all).
> This should protect the multiplexer(s) from hanging if someone is 
> hammering the processor with
> number of requests it can't handle.
> The multiplexer should actually return an error page if it can't pass 
> the request , but I haven't
> found a way to do that without locking up the multiplexer.
> I've also added AVAIL property to the server status page, which shows 
> how available the processor
> has been to the multiplexer with last requests (100 = ok, 0 = not 
> available at all).
> 
> Configuration variables:
> ProcessorWaitTimeout 2 10 # First argument defines the maximum time 
> multiplexer waits for the
> processor (defaults to 2 seconds), second argument defines the number of 
> steps between maximum
> waiting time and no waiting time (defaults to 10 and is optional).
> 
> 
> * Processor server environment configuration directive has been changed. 
> We added this style of
> directive because of new variables coming in the future that need to be 
> specified per processor (eg.
> nice level). This addition also allows us to set further possible 
> restrictions to specific
> processors (cgroups, memory limit?). If people would really like to use 
> the old style, then I can
> supply with a modified version of this patch (which then also lacks the 
> feature of nice level).
> 
> Example processor configuration:
> <Processor [unique string processor identifier]>
>     User bob # Processor user
>     Group  bob # Processor group
>     Chroot /home/bob # Processor chroot (optional)
> 
>     # Optional nice level, this is relative to main httpd process's nice 
> level
>     NiceLevel   0
> 
>     # Additional server environment variables can be overriden here
>     MaxProcessors       10  # total number of processors at the same time
>     MinSpareProcessors  3   # how many idle processors to keep alive (to 
> handle request spikes)
>     MinProcessors       0   # minimum processors that will always be 
> kept alive (idle or working).
> </Processor>
> 
> In <VirtualHost> you must use "ServerEnvironment [processor 
> identifier]". The MaxProcessors,
> MinSpareProcessors and MinProcessors directives should still work within 
> <VirtualHost> directive.
> 
> 
> * Server status now displays the child scoreboard status. This is more 
> useful for debugging.
> 
> 
> * Bugs fixed:
> - MinProcessors and MinSpareProcessors should now work correctly.
> - Multiple definitions of Processors with same senv is not allowed
anymore.
> - Fixed "Could not pass request to proper child, request will not be 
> honoured." error hanging the
> multiplexer for 10-15 seconds.
> - Fixed IdleTimeout and ExpireTimeout not set to default if it was 
> removed from configuration and
> graceful was used
> - Fixed invalid error message for MinProcessors (stating that the 
> MaxProcessors directive is invalid)
> 
> Note: As always, this is experimental. Use at your own risk. For 
> information we are running this on production environment for 2 hours 
> now. No sparks so far. Everyone can make their conclusions from there.
> 
> ***
> 
> 
> On 11.03.2009 14:32, Stefan Klingner wrote:
>> Thanks for your reply. It was missconfigured. I have fixed it and now it
>> works with 2.2.10. Great! Now I only need to build a correct debian
style
>> package and write some little documentation on my website as promised.
>> Whats about the latest version of the patch? May I be allowed to test
it?
>> Where can I download it?
>>
>> On Wed, 11 Mar 2009 13:30:30 +0200, Janno Sannik<[email protected]>  wrote:
>>    
>>> 2 things to check:
>>>
>>> 1) Might be misconfigured. Give us all peruser config.
>>> 2) Don't know about debian, but on centos 4 then compiling with gcc3.2
>>> it produces same output. Then compiled using gcc4 it works fine.
>>>
>>> Janno
>>>
>>> On 11.03.2009 12:12, Stefan Klingner wrote:
>>>      
>>>> [Wed Mar 11 11:02:48 2009] [notice] child pid 6265 exit signal
>>>> Segmentation
>>>> fault (11)
>>>> [Wed Mar 11 11:02:48 2009] [notice] child pid 6266 exit signal
>>>> Segmentation
>>>> fault (11)
>>>> [Wed Mar 11 11:02:48 2009] [notice] child pid 6267 exit signal
>>>> Segmentation
>>>> fault (11)
>>>>
>>>>        
>>> _______________________________________________
>>> Peruser mailing list
>>> [email protected]
>>> http://www.telana.com/mailman/listinfo/peruser
>>>
>>>
> 
-- 

web: http://www.mephisto23.com
_______________________________________________
Peruser mailing list
[email protected]
http://www.telana.com/mailman/listinfo/peruser

Reply via email to