On Thu, 2006-02-23 at 14:57 +0100, Christoffer Hammarström wrote: > Can you > > really run ulimit -n 8192 after having removed xprint? > > > > Yes, i can. This is because i've added the following lines to > /etc/security/limits.conf: > > * soft nofile 8192 > * hard nofile 32768 > > I'm sorry for not stating this earlier.
OK, but then... > The problem is not Xprt or xprint itself, but that the ulimit is set too > low for my daily usage, in /etc/init.d/xinit > I'm unable to change it, and the values set in /etc/security/limits.conf > are ignored. This doesn't make sense. If you can change /etc/security/limits.conf (i.e. you do have superuser rights) than why can't you likewise change the value in /etc/init.d/xprint to suit your needs ? > > > > As far other programs breaking, can you be more specific which ones? > > How much memory does your system have? > > The first time i discovered it i was running an ant compile of my java > software project with many other terminals open on the desktop. I opened > some more terminals, and then the build failed even earlier. > > Now after setting the ulimit higher, i can build again. Increasing ulimit here sounds fine, but won't that mean Xprt will no longer be interfering with the build? It sounds like your ant build is the real problem. You need the default ulimit -n to be 1024 for everything else, but increase it only for the shell running the build. After increasing to 8192 in /etc/security/limits.conf, have you found that both Xprt runs *and* the build proceeds without failure when all the xterms are still open? > > My memory right now looks like: > > $ free -m > total used free shared buffers cached > Mem: 2008 924 1083 0 42 532 > -/+ buffers/cache: 348 1659 > Swap: 3812 0 3812 No problems here. > Also, i'm not sure if it's the right way to get the number of open > files, but here you go: > > # lsof 2>/dev/null|wc -l > 3471 Feel free to suggest a better metric than lsof. But you need to compare that total value to Xprt's contribution to get meaning out of it. > It sets both the hard and the soft limit (it should be enough to set the > soft limit, right?) without first checking if the hard and the soft > limit are not set higher already. > If I'm reading it right you only need to increase the ulimit value for your ant build. Other processes (such as Xprt) don't need a higher value, only the process running the build needs it. ulimit -n only affects the current process (the calling shell), not other processes. I'll downgrade this bug from critical since it appears to be specific to your system. If we can agree it's the ant shell that needs the higher ulimit, not Xprt, then we can close this bug. Can you explain what led you to believe Xprt was the cause of the problem? Xprt's use of ulimit -n 1024 should affect it, and it alone, not other processes. Drew
