On Thu, 2006-02-23 at 16:19 +0100, Christoffer Hammarström wrote: > > How about only setting the ulimit to 1024 if it's lower than 1024? > > I want to contribute something useful to this discussion :) > I believe something like the following patch should fix the problem: > > --- xprint 2006-02-23 16:11:11.000000000 +0100 > +++ xprint.new 2006-02-23 16:11:43.000000000 +0100 > @@ -202,7 +202,7 @@ > umask 022 > > # Bump limit for per-process open files to ensure that Xprt can open > many many > fonts > -ulimit -n 1024 > +((`ulimit -n` < 1024)) && ulimit -n 1024 > > ############################################################################
Thanks for the patch. I've thought about whether something like that might help. However upon reflection I don't think it's really what we want. You're right that if the default ulimit is less than 1024 then we want xprint to increase it to 1024, which it's currently doing. What your patch does is provide Xprt with a larger limit, if the default limit in /etc/security/limits.conf is larger than 1024. But the thing is, Xprt itself does not need more than 1024 (by my count it's using 12 open files). So by restricting itself in this case to only 1024, Xprt is in a sense *saving* you resources. I think you've now successfully arranged your system so that your default user limit is 8192, correct? You've now set /etc/security/limits.conf to provide that. So when you login, ulimit -n already shows 8192, and your ant build is good to go, correct? Did you make the change to /etc/security/limits.conf *after* you had switched Xprint off? What I expect then is that you can reinstate Xprint, let it run with its lower limit of 1024, but when you log in to your own account, you should still be seeing the same 8192 limit that you see now without Xprt running. Xprt's lower file limit should not be affecting any of your other processes, which should run with the 8192 you've given them in /etc/security/limits.conf. The causality I'm expecting is that your ant build now runs because you changed /etc/security/limits.conf, *not* because you switched Xprt off. Can you confirm this causality? If you reinstate Xprt, but find that ulimit -n on your normal account has been degraded to 1024 rather than the 8192 you set in /etc/security/limits.conf, then let me know, and we'll take it up further on the mailing lists as Steve suggested. But if your account limit is still fine and large, then we can be happy we understand what's happened and can leave this bug closed. Thanks for your cooperation, Drew
