On Jun 1, 2012, at 5:31 AM, Sarah Maman wrote:
Hello Nate,
As agreed at the conference in Lyon, here's a screen printed my instance of Galaxy (please look at the end of this mail), but the layout is not exactly the same as that seen in the instance of Galaxy on the public server.
Hi Sarah, This error occurs when the cluster job's standard output and standard error files aren't written where Galaxy expects them. The cluster job runners will attempt to put them in database/pbs/ by default (configurable via cluster_files_dir in universe_wsgi.ini). If you can successfully execute this on the command line: $ qsub -o /path/to/galaxy/database/pbs/test.o -e /path/to/galaxy/database/pbs/test.e test.sh And have those test.o and test.e files exist once the job is complete, then it should work in Galaxy.
To further explain my approach, here are the steps of my local installation: 1 In January, I've installed a local instance of Galaxy (connected to our cluster) from a source repository: tarball availbale here : http://dist.g2.bx.psu.edu/galaxy-dist.b258de1e6cea.tar.gz 2 In April / May, I've installed Mercurial, recovered sources with hg clone (Date: Wed March 07 2012, changeset: 6799:40 f1816d6857) , then updated galaxy sources with all changes and settings made between January and March. Therefore, the configuration file universe.ini of March was more complete than universe file of January. Can I just make a tkdiff of these two configuration files (January to March) and copy / paste the code added?
Yes, you can diff and add the new options from the new version of the config file.
Moreover, on my instance, if I use the -- reload option with run.sh script, port 80 is no longer available. So, I must kill the python process underway before running the script run.sh. Therefore, the service is interrupted for users.... Do you have an idea to avoid this interruption ?
Local jobs will always be lost when you restart the Galaxy server process. The only solution to this problem at the moment is to run all tools on a cluster. One trick you can use if you'd like to use your Galaxy server to run most jobs is to configure your Galaxy server as a cluster node and submit tools to it by default.
Concerning bug reports, is it possible to configure my local instance of Galaxy so that the mail 'report bug' is sent to the administrator (defines in galaxy configuration file universe) instead of being sent to the Galaxy team?
Yes, in universe_wsgi.ini, see smtp_server, as well as smtp_username and smtp_password if necessary, and error_email_to. --nate
Thank you in advance, Sarah Maman
<moz-screenshot-4.jpg>