Waiting for site to load

[guyleonard]

The demo script seems to run through correctly for all steps up to 9, which just sits at a loading screen and gives this error "This site can’t be reached" when trying to access it in browser.

Step 8. Startup GenomeHubs Ensembl mirror
c8f00fceb15df551521befcd312d1c60207c32fcf3ab7c89d975656792f0c008
Step 9. Waiting for site to load
........................................

Sorry, not sure what more data I can give to you to troubleshoot this...I still need to find a machine where I can run as UID1000 maybe it is related?

[sujaikumar]

Hi Guy

Thanks for pointing this out. We've seen this on rare occasions too. The ensembl startup script doesn't always load the images correctly, so it needs to be restarted repeatedly till it does so, and this loop at the bottom of https://github.com/genomehubs/demo/blob/master/import.sh is where the script is getting stuck while waiting for the site to load images correctly:

until $(curl --output /dev/null --silent --head --fail http://127.0.0.1:8081//i/placeholder.png); do
    printf '.'
    sleep 5
done &&

So the solution for now is to terminate the import.sh script and manually rerun the genomehubs ensembl docker container like so:

docker stop genomehubs-ensembl && docker rm genomehubs-ensembl

docker run -d \
           --name genomehubs-ensembl \
           -v ~/demo/genomehubs-import/ensembl/gh-conf:/ensembl/conf:ro \
           --link genomehubs-mysql \
           -p 8081:8080 \
           genomehubs/easy-mirror:17.03.23

If that doesn't work, then just stop the docker container and try again as above. (Sorry - we haven't been able to figure out ANY other way of getting it to work other than restarting it till it does - it seems to be an artifact of the caching optimisations done by ensembl - but I could be wrong).

[guyleonard]

Hey Sujai,

Thanks for the super quick response! No worries, these things sometimes happen... I will give that a try.

However in the meantime I spun up a Ubuntu Xenial AMI and tested the demo there and it works perfectly, so it's either a local condition that I have that is stopping the demo from completing, or it is back to the not being UID1000...

Cheers,

Guy

[sujaikumar]

Cool! Glad the brand new xenial ami worked fine. That's how we tested it too, so we haven't found all the places GenomeHubs could fail in non-standard situations and how to recover from those failures...