Readthedocs.org: There was a problem with Read the Docs while building your documentation. Please report this to us with your build id (7427897).

Created on 3 Jul 2018  路  35Comments  路  Source: readthedocs/readthedocs.org

Details

Expected Result

Build success

Actual Result

Build failure with no error message or any easy way of debugging!

Support

Most helpful comment

i adopted the project and they appear to build now,
https://clifford.readthedocs.io/en/tools_merge/

All 35 comments

@arsenovic also has experienced failed builds with the same project

The error is weired! Can you try restarting your build?

Just triggered a new build of latest
https://readthedocs.org/projects/clifford/builds/7448400/

It may be related to time/memory limits

Hello please i am having the same issue. here is my URL: updatedgurudevguide.readthedocs.io
updatedgurudevguide.rtfd.io

It keeps failing to to pass the build process please what should i do?

@stsewd would I not get a timeout error if it failed for that? I will try removing my more computationally intensive notebooks and see if that helps with a potential out of memory error...

@hugohadfield yeah, but sometimes we can't show a proper message https://github.com/rtfd/readthedocs.org/issues/3613

@MagnificentRimsy I can see your docs are failing for another reason AttributeError: 'NoneType' object has no attribute 'note_implicit_target' https://readthedocs.org/projects/updatedgurudevguide/builds/7450633/

if i pay more for the membership and adopt this project, can the memory limits be lifted for this?

@stsewd how can I find out what the time/memory limits are so I can avoid hitting them?

@hugohadfield the limits are:

  • 15 minutes
  • 1GB of memory

https://docs.readthedocs.io/en/latest/builds.html

Here you can find some help https://docs.readthedocs.io/en/latest/guides/build-using-too-many-resources.html, if that doesn't work, you need to request more time/memory for your project and wait for a maintainer accept it.

@arsenovic

if i pay more for the membership and adopt this project, can the memory limits be lifted for this?

Help is always appreciated, I'm not sure if rtd has this kind of rule, what I saw: people just request more time/memory for their project with an explanation and wait.

@MagnificentRimsy I can see your docs are failing for another reason AttributeError: 'NoneType' object has no attribute 'note_implicit_target' https://readthedocs.org/projects/updatedgurudevguide/builds/7450633/

@MagnificentRimsy you may be interested in https://github.com/rtfd/readthedocs.org/issues/4341

@stsewd OK I've never encountered that error. thank you so much for point it out for me. I wish you could please show me how to fix it, please.

so, is there a method to determine if memory limits are the source of this issue?
if that is the issue, can we request more memory?

in addition, we could build only on releases, instead of for each commit. this would result in significantly more resource savings for rtd.

Our last build failed in 445.0002 seconds which is around 7 and a half minutes so we are definitely within time constraints..

I wish you could please show me how to fix it, please.

@MagnificentRimsy you need to create a requirements file and pin to the sphinx version without the bug https://github.com/rtfd/readthedocs.org/issues/4341#issuecomment-403379579. If you need more help, please ask on the other issue. Thanks!

@hugohadfield this is usually a problem with memory limits, the second error is very weird. Can you try building locally and see how many resources consume in your computer?

i get this on my laptop,

       Build finished. The HTML pages are in _build/html.
        Command being timed: "make html"
        User time (seconds): 37.84
        System time (seconds): 3.92
        Percent of CPU this job got: 77%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:54.00
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 140936
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 4
        Minor (reclaiming a frame) page faults: 1409851
        Voluntary context switches: 23246
        Involuntary context switches: 11052
        Swaps: 0
        File system inputs: 200
        File system outputs: 37808
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

i adopted the project and they appear to build now,
https://clifford.readthedocs.io/en/tools_merge/

any chance we could get some help on on this? we really like the service, and would be happy to pay more for support

@humitos Can you please take a look into this?

any chance we could get some help on on this? we really like the service, and would be happy to pay more for support

There some Gold Membership that you can consider: https://readthedocs.org/accounts/gold/subscription/

Although, we tend to not charge open source projects at all. If your project is not open source, you may want to consider using readthedocs.com (our corporate site/solution).

I didn't take a deeper look to the problem yet, so I'm not sure that it's a memory thing. I need to check the logs and make some tests to be sure and come back with more info.

clifford is open-source, and i have a minimal gold membership in attempts to get the doc builds fixed.
we would like to help fix this, but are not sure how.

@arsenovic I just triggered a new build of clifford and it did pass: https://readthedocs.org/projects/clifford/builds/7530889/

I'd say that it's a problem of memory consumption. Although, sometimes it passes because during the whole time the build is running the builder doesn't receive another big project to build. But, in case it receives another big build to process, one of them is killed since they do not keep both in memory.

If my supposition is correct, increasing the memory limit of your project won't make any difference. I have a proposed solution for this problem at #4403

@humitos thanks for looking into this. our docs are using nbsphinx, which executes a lot of jupyter notebooks. i suspect this is the memory hog.

also, wouldnt restricting doc-builds to tags/releases instead of every commit will save a lot of resources, and allow higher limits for everything?

@humitos any idea of when this could be solved? possible solutions;

  1. we can pay for more memory
  2. RTD makes option to only build tagged versions, but with more memory allocated
  3. RTD increases mem limit

i dont think our docs can be trimmed down in memory, because of the format we are using (jupyter notebooks in sphinx with nbsphinx).

without a fix, i am afraid we are going to have to move back gh-pages, which i dont want to do.

@arsenovic I'm working on a solution for this. Since it involves some changes in the server architecture it may take some days and testing to be stable and reliable.

I've already proposed a solution to the team and I'm waiting for some feedback on it. I'll come back to you when I have this reviewed, deployed and tested.

great, thanks for letting me know.

@arsenovic the solution was just deployed and we are testing it now. I've already enabled this change into your project and triggered a new build. It passed.

I'd like you to keep an eye on these builds and let me know if you find any issue while building regarding memory issues. Thanks!

@humitos thank you so much for the support, I am a big fan of read the docs and glad to be able to keep using it!

@hugohadfield clifford is building now. I increased the resources and route its builds to a specialized server for these kind of projects.

I'm closing this issue here, but feel free to reopen if you consider necessary. Also, if you have any feedback, it's appreciated. Thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

boscorelly picture boscorelly  路  4Comments

humitos picture humitos  路  4Comments

cagataycali picture cagataycali  路  4Comments

davidfischer picture davidfischer  路  4Comments

krzychb picture krzychb  路  4Comments