I agree with Henrik (both clarifications) For the record, the error happens with a surprising value in aSize.
It happens when aSize is as low as 260 o.O sebastian o/ On May 24, 2012, at 5:33 AM, Henrik Sperre Johansen wrote: > On 23.05.2012 20:18, Sven Van Caekenberghe wrote: >> On 23 May 2012, at 19:48, Marcus Denker wrote: >> >>> No, the image as it is now just quits. Delayed our deployment of the ESUG >>> registration server >>> for some weeks... normal seaside use, image quites after a day. >>> >>> It's far from obvious. >>> >>> I think the image should work out of the box. Why destinguish between >>> deployment and development? >>> What is good in deployment is for sure gut in development. > It's the other way around in this case, what's good in development is not > always so good in deployment. > In development, you want to be notified of issues as soon as possible. > If they still slip through to deployment, you want them dealt with as > gracefully as possible. > > >> It might be a bit surprising, but I think Hendrik's reasoning is quite good: >> you don't want to keep on expanding when there are problems not freeing >> resources that are limited. A good server needs resource limits. >> >> We can discuss more tomorrow… >> >> Sven >> >> >> > Well, both that, and the fact it can't be done safely. > The process of increasing its size might lead to lost signals. > > 99% of the time, setting the size at startup to a larger value than the > default (before anything but the input semaphore is registered) is a better > approach than increasing automatically, and in the remaining 1% it is better > to fix whatever application issue is causing semaphore leaks anyways. > > Cheers, > Henry >
