> >> Seeing the work that is done on nginx as Daily changelog shows I was > >> thinking the same, that eventualy nginx will replace httpd (it cannot > >> replace apache). > >> About that "too many files open", I run it this once, but Stuart > >> Henderson suggested to alter the values in /etc/login.conf. I was > >> expecting some decent values there, but I found out from FAQ that the > >> default file has the corespondent values for the minimal hardware > >> system OpenBSD is able to run on, so the giant machines need > >> adjusting. > > > > On Wed, Mar 28, 2012 at 11:44 PM, Theo de Raadt <dera...@cvs.openbsd.org> > wrote: > > Balony. > > > > If software cannot cope intelligently with soft resource limits, > > then such software is probably broken. > > > > Otherwise, let's just remove the entire resource limit subsystem, ok? > > No need to remove it I think, because the sole usage of it has a > purpose since you've put it there from the start. > I can't call xxxterm as being probably broken because my knowledge and > position don't allow me to do that. This package asks for minimum 1024 > file descriptors
What happens if it opens 1025 files? > and recommands 2048. What happens if it opens 2049 files? > I modified openfiles-max in > login.conf. That was the closest place I found to fulfill the request. > The other application is shotwell, it crashes when you try to open in > thumbnails mode a direcotry full of pictures. I don't know why the > developers used the opening all files at once approach. So you crank your limits. What happens if it opens 1 file more than your limits? You crank the limits, again. What happens if it opens 1 file more than your new limits? When do you realize that you are the problem, because you don't tell the developers to fix their software so that it works in the resource limits allocated to it? Instead, you'll crank your file limits to... let me guess, unlimited? And when you hit the system-wide limit, then what happens? Then it is our systems problem, isn't it.
