Traceback (most recent call last):
File "xxx.py", line 115, in <module>
File "/usr/lib/python2.5/xmlrpclib.py", line 1147, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.5/xmlrpclib.py", line 1437, in __request
File "/usr/lib/python2.5/xmlrpclib.py", line 1201, in request
return self._parse_response(h.getfile(), sock)
File "/usr/lib/python2.5/xmlrpclib.py", line 1340, in _parse_response
File "/usr/lib/python2.5/xmlrpclib.py", line 787, in close
xmlrpclib.Fault: <Fault 2: "'[Errno 31] Too many links:
'/home/trac/trac/attachments/ticket/32433'' while executing
Is there a way to close the xmlrpclib.ServerProxy. I think that is
what caused this error. Every time I upload a file I create a service
that connects to trac. I do that because the filename of the file I
want to upload comes on stdin.
I found this:
Too Many Links
There are too many hard links to a file or directory on a filesystem.
The exact number allowed is file-system dependent. Eg
XENIX_LINK_MAX = 126, /* ?? / SYSV_LINK_MAX = 126, / 127? 251?
/ V7_LINK_MAX = 126, / ?? */ COH_LINK_MAX = 10000,
while /usr/src/linux-2.4.19/include/linux/ext3_fs.h has
1. define EXT3_LINK_MAX 32000
and /usr/src/linux-2.4.19/include/linux/reiserfs_fs.h has
1. define REISERFS_LINK_MAX (MAX_US_INT - 1000)
(for maximum unsigned integer on the system).
This could be caused by a directory having too many subdirectories
(each subdirectory has .. as a hardlink to it's parent directory which
causes that directory's hardlink count to be increased by one. So yes,
this does mean that you are limited to 32000 subdirectories in one
directory in ext3, even if you have hashdirs enabled.) As a
consequence of this you can stat(2) a directory and add one (for ..)
and you will know how many directories are in the current directory.
(or subtract one (for .) to find out how many subdirectories there
Some file systems (such as FAT) don't have hardlinks so the hardlink
count can't overflow, and you can't rely on the hardlink count of a
directory to be representive of how many subdirectories it has.
What a confusing world we live in.
I did reach the 32000 tickets. I have exactly:
31999 folder for ticket# on my ext3.
ls -l |wc -l
How do I increase that number on ext3?
I'm not sure you can. But I remember reading about a "sharding" scheme
for attachments that would solve the issue. Here's the ticket:
There's a patch attached, but it didn't get a review yet.
Well, when lots of SVN users started hitting limits like that for
revisions, they just added a second directory level to handle the
situation. I don't think many Trac instances have, to this point,
been used in a such a way that they've hit this limit.
>> I did reach the 32000 tickets. I have exactly:
>> 31999 folder for ticket# on my ext3.
>> ls -l |wc -l
>> How do I increase that number on ext3?
> Well, when lots of SVN users started hitting limits like that for
> revisions, they just added a second directory level to handle the
> situation. I don't think many Trac instances have, to this point,
> been used in a such a way that they've hit this limit.
Implementing this two level architecture seems reasonably easy to do
so it is either that or you move to another filesystem, which is
simpler if you don't want to extend trac.
Theres a lot of fs that don't have this problem besides Reiserfs:
ext4 with an extension has no limits (64k otherwise)
santagada at gmail.com
This is not a failure in the client but run time error in the
server-side instead (otherwise `xmlrpclib.Fault` wouldn't be the exc
type being raised ;o) . Details are in the log file, and well possible
root causes in the other msgs in this thread ;o)
> Is there a way to close the xmlrpclib.ServerProxy. I think that is
> what caused this error.
So your client code (i.e. using ServerProxy) should be just fine ;o)