ulimit -n to small

ulimit -n to small

[Heinrich Goetzger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 951 bytes --]

Hi,

my zsh 4.2.5 on gentoo has a problem with the number of file descriptors.
They can not raise the hard limit even with the -S set as mentioned in [1]:

$ ulimit -n
1024
$ ulimit -SHn 2048
ulimit: can't raise hard limits
$ ulimit -Sn 2048 
ulimit: value exceeds hard limit

But I need a value for file descriptors > 5000 for some java application.
With ksh and zsh @ root it works as expected:
ulimit -n 1024
# ulimit -n     
1024
# ulimit -n 8192
# ulimit -n     
8192

How can I change the hard limit for the file descriptors?

I tried to find something in the archive, but the site [2] is not accessable
and the archive at [3] had no matching articles.

Thanks.

Cheers.

Heinrich

[1]: http://zsh.sunsite.dk/Doc/Release/zsh_16.html
[2]: http://www.zsh.org/mla
[3]: http://news.gmane.org/gmane.comp.shells.zsh.user

-- 
+++ GMX - Die erste Adresse für Mail, Message, More +++

1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: ulimit -n to small

[Nikolai Weibull]

Heinrich Goetzger, April 19:

> … I need a value for file descriptors > 5000 for some java
> application.

No help at all, but, seriously, what application needs more than five
thousand files open at the same time?,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: ulimit -n to small

[Heinrich Goetzger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1187 bytes --]

> Heinrich Goetzger, April 19:
> 
> > I need a value for file descriptors > 5000 for some java
> > application.
> 
> No help at all, but, seriously, what application needs more than five
> thousand files open at the same time?,
This is the "Acrobat Viewer Bean" [1] it scans the files in /usr/share/fonts
for some reason. I'm evaluating this application right now.

Just try: 'find /usr/share/fonts/ | wc -l'
it gives me 4992 which can be compared with the number of files at
/proc/[1st PID of the java bean process]/fd directory. The difference isn't
big.
And the problem is, if the viewer can not open all requested files, it
refuses correct working. For some reason, this seems to be fine on windows.
But this isn't part of this list and of this thread.

If you have another solution for either the number of open files or a good
free pdf-viewer-library for java let me know.

It becomes OT now but this is only to answer the understandable question.

Kind regards and good night

Heinrich

[1]: http://www.planetpdf.com/planetpdf/acrobat/bean/main.html

-- 
+++ GMX - Die erste Adresse für Mail, Message, More +++

1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: ulimit -n to small

[Nikolai Weibull]

Heinrich Goetzger, April 19:

> > > I need a value for file descriptors > 5000 for some java
> > > application.

> > No help at all, but, seriously, what application needs more than
> > five thousand files open at the same time?,

> This is the "Acrobat Viewer Bean" [1] it scans the files in
> /usr/share/fonts for some reason. I'm evaluating this application
> right now.

Shouldn't it close the files after it has finished scanning them?
Perhaps the Java GC isn't freeing stuff correctly?

> Just try: 'find /usr/share/fonts/ | wc -l' it gives me 4992 which can

Wow, 4992 files in your fonts directory?  That's quite a bunch,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: ulimit -n to small

[Heinrich Goetzger]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1075 bytes --]

> Heinrich Goetzger, April 19:
> 
> > > > I need a value for file descriptors > 5000 for some java
> > > > application.
> 
> > > No help at all, but, seriously, what application needs more than
> > > five thousand files open at the same time?,
> 
> > This is the "Acrobat Viewer Bean" [1] it scans the files in
> > /usr/share/fonts for some reason. I'm evaluating this application
> > right now.
> 
> Shouldn't it close the files after it has finished scanning them?
> Perhaps the Java GC isn't freeing stuff correctly?
It should, probably, but due to a lack of source code access I can not check
what's goning on, probably there is a simple close missing. Haven't found
anything else yet.

> 
> > Just try: 'find /usr/share/fonts/ | wc -l' it gives me 4992 which can
> 
> Wow, 4992 files in your fonts directory?  That's quite a bunch,
:-) This is on a gentoo box where you can easily emerge lots of fonts.
Viva la emerge ;-)

Cheers

Heinrich

-- 
+++ GMX - Die erste Adresse für Mail, Message, More +++

1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

Re: ulimit -n to small

[Peter Stephenson]

"Heinrich Goetzger" wrote:
> my zsh 4.2.5 on gentoo has a problem with the number of file descriptors.
> They can not raise the hard limit even with the -S set as mentioned in [1]:

Only the superuser can raise hard limits; that's the real difference
between them and soft limits.  You can raise the soft limit to the hard
limit, or lower the hard limit, but that's it.

If you have superuser access or know someone who has, note that as
limits are inherited you need to raise the hard limit in a parent
process of the shell where you actually want to run the programme.
(In other words, running "su", raising the hard limit, and exiting
doesn't work because you're back where you started.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************