On Thu, 2006-02-23 at 13:47 +0100, Christoffer Hammarström wrote: > > /etc/init.d/xprint sets "ulimit -n 1024". > > This makes other programs break with "too many open files", but more > importantly, > i can't set a higher ulimit in bash: > > $ ulimit -n 8192 > -bash: ulimit: open files: cannot modify limit: Operation not permitted > > My workaround was to "update-rc.d -f xprint remove" since i don't need > printing anyway. >
I'm not sure that I can see what the problem is. ulimit -n 8192 does not run even when Xprt is not running, the limit it can be set to is -n 512, though higher values can be set as su. As far as I can tell this behaviour is system controlled somewhere, not related to Xprt. Can you really run ulimit -n 8192 after having removed xprint? Furthermore as far as I can tell 1024 is a standard ulimit for -n, at least it's reported as such by default from the bash command line (ulimit -a). As far other programs breaking, can you be more specific which ones? How much memory does your system have? If you want to sustain this bug, you'll need to convince me that Xprt is causing tangible problems. How much system resources is it using? What exactly is happening when your other programs break. What is Xprt's open file usage? Measure it with "lsof | grep Xprt | wc" and compare with the total "lsof | wc". I'm not convinced yet there's a problem. Drew
