CVS linux server has too many projects, server command results in “argument list too long”

Question

I have a CVS server with thousands of CVS repositories hosted on it. It runs with a typical configuration where projects that allow anonymous pserver access are added to the cvs command line with an --allow-root argument. The problem is, there are so many projects, that the cvs command now results in an "argument list too long" error.

At this time, my current solution has been to hack the CVS source code, changing the CVS command line argument from "--allow-root" to "--ar" . It works, but the possibility exists that I will, at some point, exceed the command line length again.

I examined using xargs . The problem with it, it appears that it would have to run the CVS command for each repository, one at a time, until it finds the one specified in the incoming CVS command.

I tried to write a wrapper that could get the repository name from the incoming client command line, but I was unable to do so. Possibly just a lack of knowledge on my part, but I tried for a while, and couldn't find a method that worked.

I looked at the cvs-pserver script, but it does the same thing, places all the repositories in the command line.

I looked at cvsd , and it too has the same limitation.

I'm officially out of ideas. The most elegant solution is the cvs wrapper that can get the repository name from the incoming client command. I'd love to see that work, but any useful input would be greatly appreciated.

Answer 1

In Linux kernels >= 2.6.23, this issue has been addressed somewhat . The maximum argument list size was increased to about 25% of the maximum stack size.

On my Linux 64-bit system, where the maximum stack size is by default about 8MB, that leaves about 2MB of space for the argument list. With 100 bytes each for example, that allows for about 20,000 program arguments.

Since you are using a 2.6.18 kernel, you should look at updating you kernel. This should work around this particular issue and you would gain all the additional benefits (and hassles, I suppose) of a newer kernel.