Long project names fail with shell error.

[ckuehl]

I am seeing the following build error:

/bin/sh: 1: /home/docs/checkouts/readthedocs.org/user_builds/rackspace-cloud-core-infrastructure-services-user-guide/envs/latest/bin/sphinx-build: not found

I also see:

doc_builder
-----

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/readthedocs/projects/utils.py", line 85, in run
    stderr=subprocess.PIPE, env=environment)
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

No settings have changed on our project, so can someone please take a look and see what is preventing our builds?

Thanks!

[guyfawcus]

Strange. If you try to build it again (using the 'Build' button on your project page) does it still fail? May have just been a temporary server issue.

Link to builds.

[ckuehl]

@maelstrom59 I just triggered another build and it also failed for the same reason.

[guyfawcus]

Looks like this is something for @ericholscher. Sorry I can't be of any help.

[ericholscher]

This is really odd. The pip inside the virtualenv is giving this error:

-bash: /home/docs/checkouts/readthedocs.org/user_builds/rackspace-cloud-core-infrastructure-services-user-guide/envs/latest/bin/pip: /home/docs/checkouts/readthedocs.org/user_builds/rackspace-cloud-core-infrast: bad interpreter: No such file or directory

I'm looking into it, but it's something odd.

[ericholscher]

I think this might be a line length limit error on the shebang that is included at the top of the pip file >:x

[ericholscher]

I think the name of your project is too long, if it was shorter it would work... I don't really know what to do about it on the OS side :/

[ckuehl]

@ericholscher Interesting. Did something change in the last couple of months with the paths? I see that this was working about two months ago, but the paths were similar to the following in those logs:

/var/build/user_builds/rackspace-cloud-core-infrastructure-services-user-guide/checkouts/latest

Is there a way to rename the path used without changing the actual name/title of the document itself?

[ericholscher]

Yea, used to use /var/build/user_builds instead -- I never realized that having the paths in there would cause issues >:x

The path is from the slug, which is what will be in the URL, and is generated from the title on import, you can rename the title (what displays in the UI) after the slug is created, but we don't let users change slugs. I could also change the slug for you, if that made sense, but it would break the old URLs if those are already in wide use.

[ckuehl]

@ericholscher Can you change the slug to "rackspace-core-infra-user-guide"? We're fine with the existing URLs being broken as these aren't in use by a large number of users yet. Thanks!

[ericholscher]

Great, thanks. That fixed it.

I'll keep this ticket open for researching a real fix to the actual problem
:)

On Mon, Oct 27, 2014 at 2:00 PM, Christopher Kuehl <[email protected]

wrote:

@ericholscher https://github.com/ericholscher Can you change the slug
to "rackspace-core-infra-user-guide"? We're fine with the existing URLs
being broken as these aren't in use by a large number of users yet. Thanks!

—
Reply to this email directly or view it on GitHub
#994 (comment)
.

Eric Holscher
Maker of the internet residing in Portland, Or
http://ericholscher.com

[ckuehl]

@ericholscher Awesome - looks good now. Thanks for getting our docs taken care of.

[fergonco]

I run into this same issue as well. After trying and trying, finally I found this issue and created the same project with a shorter name. It works now.

Maybe it is a good idea to limit the length of the project name until this issue is solved.

Many thanks for the awesome project, in any case.

[sjagoe]

This also appears to be an issue when building a branch of a project where the branch-name is long.

[gregmuellegger]

We should find out about the maximum path length that we can support and fix this in the code.
@ericholscher Can you remember any of the investigations you did for this?

[agjohnson]

I'll take this on.

For background information here, the shebang max length is set in the kernel by BINPRM_BUF_SIZE, which defaults to 127 characters. Short of compiling a custom kernel, the easiest fix is to avoid shebang lines all together and instead call the virtualenv python with the script we're executing as an argument.