Bug#288710: setfacl with many files at cmdline -> Too many open files
tags 288710 confirmed fixed-upstream thanks At Wed, 6 Apr 2005 07:48:16 +1000, Nathan Scott wrote: > > Maybe should this bug be untagged "upstream" then ? > > Since its working on other versions of glibc (ie SLES9), odds are > its an upstream bug anyway (maybe not, but probably). At this > stage, I think we should leave it for the glibc guys to determine. Yes, this bug was already fixed in the recent glibc - it's affected only for sarge and sid. Note that the current glibc 2.3.5-1 in experimental does not have this problem. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288710: setfacl with many files at cmdline -> Too many open files
On Tue, Apr 05, 2005 at 10:32:49AM +0200, Xavier Hienne wrote: > Nathan Scott a écrit : > > Let's reassign this bug to glibc, and ask those folks to take > > a look at the problem. > > Maybe should this bug be untagged "upstream" then ? Since its working on other versions of glibc (ie SLES9), odds are its an upstream bug anyway (maybe not, but probably). At this stage, I think we should leave it for the glibc guys to determine. cheers. -- Nathan
Bug#288710: setfacl with many files at cmdline -> Too many open files
Nathan Scott a écrit : On Mon, Apr 04, 2005 at 10:58:45PM +0200, Xavier Hienne wrote: Hi, I too am encountering the very same bug on a 1900+ entry /home directory. The bug is easily reproducible : Yep, just tried it and it is indeed easy to hit with that test An even easier way to reproduce it could be : $ sh $ ulimit -n 5 $ getfacl / / / case, thanks. I've also tried this on a SLES9 machine I had handy, and the same getfacl code doesn't fail there, so I guess you're right in suggesting this is a glibc problem. Let's reassign this bug to glibc, and ask those folks to take a look at the problem. Maybe should this bug be untagged "upstream" then ? Regards, Xavier
Bug#288710: setfacl with many files at cmdline -> Too many open files
On Mon, Apr 04, 2005 at 10:58:45PM +0200, Xavier Hienne wrote: > Hi, > > I too am encountering the very same bug on a 1900+ entry /home > directory. The bug is easily reproducible : Yep, just tried it and it is indeed easy to hit with that test case, thanks. I've also tried this on a SLES9 machine I had handy, and the same getfacl code doesn't fail there, so I guess you're right in suggesting this is a glibc problem. Let's reassign this bug to glibc, and ask those folks to take a look at the problem. thanks. -- Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288710: setfacl with many files at cmdline -> Too many open files
Hi,
I too am encountering the very same bug on a 1900+ entry /home
directory. The bug is easily reproducible :
$ mkdir /tmp/dir
$ cd /tmp/dir
$ for ((i=0; i<2000; i++)); do mkdir $i; done
$ getfacl *
[...]
user::rwx
group::r-x
other::r-x
getfacl: Too many open files
getfacl: Too many open files
getfacl: Too many open files
[...]
The bug only occurs with a great number of directories, not files. Both
Woody and Sid (glibc 2.3.2) are affected. It seems that this is not an
acl bug but a glibc bug. For example, it also occurs with the getfattr
from the attr package.
After a bit of investigation, I suspect the nftw(3) function (file
io/ftw.c in the glibc sources).
Here is an excerpt of "ltrace -S -n4 getfattr *" :
<... nftw64 resumed> )= 1
nftw64(0xbfffec85, 0x08049500, 0, 0, 0x40136e48
SYS_access(0xbfffec85, 4, 0x40136e48, 0, 0xbfffb8c4) = 0
SYS_stat64(0x0804d178, 0xbfffb768, 0x40137aa0, 0x4013b4ec,
0x0804d178) = 0
SYS_open("1916", 100352, 00) = 1023
SYS_fstat64(1023, 0xbfffb53c, 0x40137aa0, 0x4013b4ec, 1023) = 0
SYS_fcntl64(1023, 2, 1, 0x0804d178, 1023) = 0
listxattr(0x0804d178, 0, 0, 0x4002a2f8, 0x400235d8
SYS_listxattr(0x0804d178, 0, 0, 0x40136e48, 0x08458098) = 0
<... listxattr resumed> ) = 0
free(0x0804b368) =
At each inner loop of nftw64, the result of SYS_open increments by one
until the kernel returns -EMFILE (Too many open files). I suspect that
the opendir() call in ftw.c is not followed by a corresponding closedir().
I have no time to look further and I hope that someone else will easily
find what's going wrong exactly.
Regards,
Xavier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288710: setfacl with many files at cmdline -> Too many open files
Hello Nathan, --Am 10. Januar 2005 09:35:54 +1100 schrieb Nathan Scott <[EMAIL PROTECTED]>: Hi Dirk, I sent this onto the maintainer, he's asked a couple of questions: On Thu, Jan 06, 2005 at 07:18:35PM +0100, Andreas Gruenbacher wrote: On Thursday 06 January 2005 04:43, Nathan Scott wrote: > FYI - wonder if we have a file descriptor leak in setfacl? > Or perhaps the nftw in there is holding too many fds open? What's in /proc/sys/fs/file-max? /proc/sys/fs/file-max is 64000 What does this give? find . -print0 | xargs -0 sh -c "cat /proc/sys/fs/file-nr" many lines ;-) with 2232146264000 2nd number varies between 1460 an 1467 Regards, Dirk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
