Database problems with startup and startup_lite #562
Comments
|
@bgruening I don't know if you have any idea about what might go wrong here? |
|
It looks like the Galaxy DB is not yet created, which the check_database.py is expecting. I think the DB will be created while Galaxy is starting for the first time (at least since 20.05). As a quick „fix“ I think you could try to change https://github.com/galaxyproject/ansible-galaxy-extras/blob/3c6fe3585aa3b82d22f74a1c3eb59afc1a2a49c0/templates/startup_lite.sh.j2#L42 with something like this or just completely replace it with a long enough sleep 😄 |
|
@bedroesb I think Andreas' suggestion was to replace https://github.com/galaxyproject/ansible-galaxy-extras/blob/3c6fe3585aa3b82d22f74a1c3eb59afc1a2a49c0/templates/startup_lite.sh.j2#L42 with his suggestion. Did you do this, and if yes, what is the output you're seeing ? |
|
@mvdbeek I misinterpreted the suggestion I think, so now I changed the line, changed .gitmodules to refer to my changed one, and tried to build it. I am unfamiliar with the build process of galaxy stable, and was wondering if I could use the github actions to generate a final galaxy stable image like it does here that I could use to test on? Or am I not looking at the right generated image on docker.io? |
|
That looks correct, at first glance it looks like some of the tests failed because they couldn't mount the cvmfs shares, and maybe that's why the tests failed ? That shouldn't be related to the |
|
The suggestion gives: |
|
You might need to add a |
|
ok step by step I will get there, now it is complaining about off course still using in ansible-galaxy-extras: and adapted docker file My try out containers are being pushed at: https://hub.docker.com/repository/docker/bedroesb/galaxy-stable Thank you for the help btw! |
|
So what the command does is to check if the host is available for requests at a given port. In the Docker Compose setup Postgres sits in another container (hostname |
|
Ok this worked! This is great, I will open some PR with the changes. But for some reason I now stumble across the same problem as with 19.09 I described here #551, and that is that ephemeris is not available when I am building on top of this base image. Funny things is, If I go into the container interactively, I do have ephemeris on my path available? |
|
The script I run in the image built looks like this: |
|
ok I solved it by adding |
|
I have now sadly new problems: When I run my image with galaxy-stable as base image, I have following error: and when I use |
|
after also changing startup.sh.j2 in PR galaxyproject/ansible-galaxy-extras#244 : |
and
Seem a bit odd to me, I‘m not sure it has something to do with the change in the PR 🤔 Is Postgres already started from a different script or do you run it twice somehow? Maybe you could check if Postgres complains about something. Do you export the Postgres data? If so you could try to remove all data to have a clean start. |
|
Ok I finally got a way of installing the workflows in a reliable way, and it even works on the current version of quay.io/bgruening/galaxy:20.05 ! I discovered that if you make use of the install_tools_wrapper.sh to install tools, there are not really problems. So I basically used the code in that wrapper to set up the database/galaxy : #!/bin/bash
# Enable Test Tool Shed
echo "Enable installation from the Test Tool Shed."
export GALAXY_CONFIG_TOOL_SHEDS_CONFIG_FILE=$GALAXY_HOME/tool_sheds_conf.xml
. /tool_deps/_conda/etc/profile.d/conda.sh
conda activate base
if pgrep "supervisord" > /dev/null
then
echo "System is up and running. Starting with the installation."
export PORT=80
else
# start Galaxy
export PORT=8080
service postgresql start
install_log='galaxy_install.log'
# wait for database to finish starting up
STATUS=$(psql 2>&1)
while [[ ${STATUS} =~ "starting up" ]]
do
echo "waiting for database: $STATUS"
STATUS=$(psql 2>&1)
sleep 1
done
echo "starting Galaxy"
# Unset SUDO_* vars otherwise conda run chown based on that
sudo -E -u galaxy -- bash -c "unset SUDO_UID; \
unset SUDO_GID; \
unset SUDO_COMMAND; \
unset SUDO_USER; \
./run.sh -d $install_log --pidfile galaxy_install.pid --http-timeout 3000"
galaxy_install_pid=`cat galaxy_install.pid`
galaxy-wait -g http://localhost:$PORT -v --timeout 120
fi
# Create the admin user if not already done
# Starting with 20.05 this user is only created at first startup of galaxy
# We need to create it here for Galaxy Flavors = installing from Dockerfile
if [[ ! -z $GALAXY_DEFAULT_ADMIN_USER ]]
then
(
cd $GALAXY_ROOT
. $GALAXY_VIRTUAL_ENV/bin/activate
echo "Creating admin user $GALAXY_DEFAULT_ADMIN_USER with key $GALAXY_DEFAULT_ADMIN_KEY and password $GALAXY_DEFAULT_ADMIN_PASSWORD if not existing"
python /usr/local/bin/create_galaxy_user.py --user "$GALAXY_DEFAULT_ADMIN_EMAIL" --password "$GALAXY_DEFAULT_ADMIN_PASSWORD" \
-c "$GALAXY_CONFIG_FILE" --username "$GALAXY_DEFAULT_ADMIN_USER" --key "$GALAXY_DEFAULT_ADMIN_KEY"
)
fiand this to close off the database/galaxy after installation of the tools/workflows/datalibraries using ephemeris: if [ $exit_code != 0 ] ; then
if [ "$2" == "-v" ] ; then
echo "Installation failed, Galaxy server log:"
cat $install_log
fi
exit $exit_code
fi
if ! pgrep "supervisord" > /dev/null
then
# stop everything
sudo -E -u galaxy ./run.sh --stop --pidfile galaxy_install.pid
rm $install_log
service postgresql stop
fiAnd this gives almost no problems (besides sometimes an API HTTP connection error which appears randomly) and I managed to update the covid-19 workflow container to 20.05 with success. I am now wondering, do I keep the subtle edits to |
When I want to build a galaxy container with version 20.05 using especially
startup_lite(both with quay.io/bgruening/galaxy and bgruening/galaxy):I encounter this problem:
This error message keeps repeating himself with
Waiting for database.I am not mounting anything in the export folder. Does somebody else encounter this problem or know what I do wrong?
The text was updated successfully, but these errors were encountered: