Re: [galaxy-dev] Slow repsonses viewing histories
Hi Nate, I have managed to update to the latest version of the default branch but I do not see the ‘max_metadate_value_size’ in my universe_wsgi.ini (this file was not changed during the update). Same thing if I use hg pull hg update stable or hg pull hg update release_15.05. Does this mean this change is not yet on mercurial and if so how can I pull this specific change (using curl?) to generate my own branch specific for the patch? Thanks, Richard On 15 Jul 2015, at 20:59, Richard Poole ucga...@live.ucl.ac.ukmailto:ucga...@live.ucl.ac.uk wrote: Just a little update - executed the SQL query and luckily only returned 20 BAM files - the most recently generated ones of course. Now makes sense this could well be the cause of the UI problem as my account became more and more unresponsive the more of these 20 BAM files I generated over the last week……….. Rich On 15 Jul 2015, at 20:38, Richard Poole ucga...@live.ucl.ac.ukmailto:ucga...@live.ucl.ac.uk wrote: Hi Nate, Ok - I can try this but I’m not an SQL database expert - far from it in fact. That query will just list ‘problematic’ datasets? I have a lot of histories with BAM files ;) Resetting the metadata needs to be done before this fix works? I ask because my history is so slow now as to be unusable…….or setting the cutoff allows Galaxy to be usable but it wipes out the metadata (which then needs resetting). I am still using universe_wsgi.ini not galaxy.ini and I don’t see the 'max_metadata_value_size’ in any section of my universe_wsgi_ini file - I guess because I’m not on latest update. I am actually not sure what version I am on as to fix an earlier issue with shared datasets (that wasn’t yet on mercurial) on the advice of a few folks I generated a branch specific for the patch using: hg branch fix_history_sharing curl https://github.com/galaxyproject/galaxy/commit/62772bc86e2504982f207a982542cbcc3faf0c65.diff|patch -p1 Also not being a huge mecurial expert I am a little unsure now how to switch back to stable branch correctly and pull the latest updates. Could you advise (sorry to be a noob)? Rich On 15 Jul 2015, at 20:22, Nate Coraor n...@bx.psu.edumailto:n...@bx.psu.edu wrote: Hi Richard, Unfortunately, you will need to reset metadata for any problematic datasets once you have updated to the latest version of 15.05 and set a cutoff value. You can find the datasets with the following SQL query in your database: select hda.idhttp://hda.id/, u.email, h.namehttp://h.name/, hda.hid, hda.namehttp://hda.name/, length(hda.metadata) from history_dataset_association hda join history h on hda.history_id=h.idhttp://h.id/ join galaxy_user u on h.user_id=u.idhttp://u.id/ where length(hda.metadata) 1048576 order by length(hda.metadata) desc; And you can reset metadata by clicking on the dataset's pencil icon in your history and clicking auto-detect. --nate On Wed, Jul 15, 2015 at 3:16 PM, Poole, Richard r.po...@ucl.ac.ukmailto:r.po...@ucl.ac.uk wrote: Hi Nate, I am indeed using later than 15.05………so I will try this fix next time I can restart the server and let you know. Richard On 15 Jul 2015, at 19:32, Nate Coraor n...@bx.psu.edumailto:n...@bx.psu.edu wrote: Hi Richard, By any chance, are you running Galaxy 15.05 or later? 15.05 includes new metadata for bam files that can cause UI performance problems with certain types of bam files. This can be limited with the new `max_metadata_value_size` in galaxy.ini (on usegalaxy.orghttp://usegalaxy.org/ we've set it to 100). I've also created a pull request to make this limiting the default: https://github.com/galaxyproject/galaxy/pull/466 However, if you are using an older version of Galaxy, this issue is not related to the problem you're experiencing. --nate On Wed, Jul 15, 2015 at 2:16 PM, Poole, Richard r.po...@ucl.ac.ukmailto:r.po...@ucl.ac.uk wrote: Hi Christian and Carl, Thanks both for the replies. To answer your questions in reverse order. I have about XX histories in my account each with an average of about XX datasets. Total data in my account is about 1TB. It is indeed an admin account and other users with close to 1TB of data do not have a similar slow down. Although their data is spread over far fewer histories. Is there a way then to prevent the file_name attribute being requested for admin accounts so I can see if this speeds things back up again? Although the Galaxy server is running on my iMac the data is stored external on a large directly attached NAS. I think I first noticed this slow down after deleting and purging a bunch of older histories to free space on the NAS. I have tried running some of the cleanup_datasets scripts but they are actually returning errors and not running right now (can give you the error messages if necessary). The slowdown is actually getting worse now and it is even slow to display tool pages, as well as often getting this error if it is really slow: Proxy Error The proxy server
Re: [galaxy-dev] cloudman galaxy - too large volume
All of the volumes will be SSD from now on, large or small (technically, gp2 type as defined here http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) but no, it's not currently possibly to specify the type via user data. Regardless, to specify the *volume_type* the volume needs to exist a priori and so if it an SSD type was created, that's what it's going to be. On Wed, Jul 15, 2015 at 11:03 AM, Alexander Vowinkel vowinkel.alexan...@gmail.com wrote: Great! Especially also witht he IO performance. Is it possible to define the volume type manually by putting 'volume_type' to the user data? So I can also have smaller volumes with SSD? Best, Alexander 2015-07-14 13:57 GMT-05:00 Enis Afgan enis.af...@irb.hr: I just fixed this here https://github.com/galaxyproject/cloudman/commit/0f6ab132958ad57a338c66387112407edbc7632d#diff-9eba488c9175de87945a13d7b7228a6dR621 This required switching to SSD-based volumes on AWS and, besides actually being able to create volumes up to 16TB now, it should give us better IO performance now. On Mon, Jul 13, 2015 at 5:06 PM, Alexander Vowinkel vowinkel.alexan...@gmail.com wrote: Hi, I get this error on cluster creation: Error creating volume: EC2ResponseError: 400 Bad Request InvalidParameterValueVolume of 2048GiB is too large for volume type standard; maximum is 1024GiB Is there a way to get a volume that big for galaxy? Best, Alexander ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] User is not allowed to view history
Thanks, Carl! I will try and update the installation to a newer version! I just got an email from the user that the history loaded again on its own. I took a look at the javascript console as you suggested but found no error messages. I'm not sure if the issue is fixed, but upgrading to a newer version of galaxy might be a good idea anyways. Thanks for all your help, it's much appreciated! On Tue, Jul 14, 2015 at 10:24 AM, Carl Eberhard carlfeberh...@gmail.com wrote: She got that error message when she clicked on settings and tried to view saved histories. It looks like this error when loading '/history/view' was fixed with release_13.02: https://github.com/galaxyproject/galaxy/commit/3deac8edfba8e8088de855789a28e7d3a328b9b5 If possible, you could update to git branch release_13.02 and get the fix. Alternately, you could apply that particular patch above to your current installation but that may cause more conflicts later if you decide to update. saw that their history wasn't loading on the right-hand side. The above does not help the underlying problem of the user's history erroring in the 'Analyze Data' page. If you or the user open the javascript console: http://webmasters.stackexchange.com/questions/8525/how-to-open-the-javascript-console-in-different-browsers and attempt to load the history, do you see any javascript errors? Do you see any errors in the server log when he/she attempts to load the history? On Mon, Jul 13, 2015 at 11:38 AM, Lina L Faller lina.fal...@gmail.com wrote: Hi Carl, Thanks for getting back to me! - The galaxy version is release_2013.01.13. - The user logged into their galaxy account and saw that their history wasn't loading on the right-hand side. She got that error message when she clicked on settings and tried to view saved histories. - It's not an imported history, she has had the same history since she first logged in. Thanks for any advice you might have! Cheers, ~Lina On Mon, Jul 13, 2015 at 11:24 AM, Carl Eberhard carlfeberh...@gmail.com wrote: Hi, Lina Apologies for the delay. A few questions, please: - What version is your Galaxy instance running? - What URL or operation is the user trying when they get that error? Is it just the 'Analyze Data' page or something else like 'galaxy/history/view?id=id'? - Is the history imported? Is it accidentally/possibly from a different user/account? On Tue, Jul 7, 2015 at 3:19 PM, Lina L Faller lina.fal...@gmail.com wrote: Hi all, I am new to maintaining the galaxy server at my institute and a user emailed me that they get the following error message when trying to view their history: Either you are not allowed to view this history or the owner of this history has not made it accessible. Is there a way to modify access privileges of the users' histories? Thanks for any advice! ~Lina ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ ___ Please keep all replies on the list by using reply all in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] ./run.sh segfault
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I have a weird issue that's just cropped up. After a new install of
galaxy (checked out on Monday from github) on a ubuntu vm, using
postgres rather than sqlite as well as a few other production
recommendations, I started playing around with the Data Libraries
functionality. I linked a bunch of fastq.gz files into galaxy (around
150 in total) and everything was working fine. I went home and the
next day, it was down.
I tried to start it up as usual (using an init.d script), it worked
for less than a minute and then disappeared again. So I tried running
it as the galaxy user using ./run.sh and I get a seg fault;
Starting server in PID 23173.
serving on http://144.124.110.39:8080
Segmentation fault
Tried again with strace
Starting server in PID 23552.
serving on http://144.124.110.39:8080
[{WIFSIGNALED(s) WTERMSIG(s) == SIGKILL}], 0, NULL) = 23552
- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=23552,
si_status=SIGKILL, si_utime=1590, si_stime=1930} ---
rt_sigreturn() = 23552
write(2, Killed\n, 7Killed
) = 7
read(10, , 8192) = 0
exit_group(137) = ?
+++ exited with 137 +++
I can't see anything odd in the log file and I've turned debugging on
in galaxy.ini. I'm at a bit of a loss. Does anyone know what might be
causing it?
Cheers,
- --
Dr. Martin Vickers
Data Manager/HPC Systems Administrator
Institute of Biological, Environmental and Rural Sciences
IBERS New Building
Aberystwyth University
w: http://www.martin-vickers.co.uk/
e: mj...@aber.ac.uk
t: 01970 62 2807
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iQEcBAEBAgAGBQJVp80YAAoJEHa0a8GkKQgIGlIH/1VfAPbs/5ApDBdyoOV5qf1y
oCOv93IojARyfI0ksSjF8NRNzw5fNp1R8AzZzomaR3SOUkBuZutre600sy0azTZw
E6gjxtMuvaMyEsOTXtToVarVJT0wTG8+5DJRIYLxtYZm7kvbZK0WuzrN2zDT6663
Rnm7zI/zBpTAyp6uXwgmz0x5gpH6KFwRcEHEbU3JWy6nj1zithJShwYPlBuhT5IB
OaPwOKflcZpZ8NBTEGsh038JrkU+eE50a9aEjQ2m/DpfM/TN9ujgEFm1dyy/iQS7
ewwQUpWJDkA/u0ZX602dsNdV2LvGuKVVMEHiQ25zaUQZ/iGTwKBQsFM2LlDybgA=
=jzYG
-END PGP SIGNATURE-
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] ./run.sh segfault
Hi Martin,
Is there anything in the syslog?
--nate
On Thu, Jul 16, 2015 at 11:26 AM, Martin Vickers mj...@aber.ac.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I have a weird issue that's just cropped up. After a new install of
galaxy (checked out on Monday from github) on a ubuntu vm, using
postgres rather than sqlite as well as a few other production
recommendations, I started playing around with the Data Libraries
functionality. I linked a bunch of fastq.gz files into galaxy (around
150 in total) and everything was working fine. I went home and the
next day, it was down.
I tried to start it up as usual (using an init.d script), it worked
for less than a minute and then disappeared again. So I tried running
it as the galaxy user using ./run.sh and I get a seg fault;
Starting server in PID 23173.
serving on http://144.124.110.39:8080
Segmentation fault
Tried again with strace
Starting server in PID 23552.
serving on http://144.124.110.39:8080
[{WIFSIGNALED(s) WTERMSIG(s) == SIGKILL}], 0, NULL) = 23552
- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=23552,
si_status=SIGKILL, si_utime=1590, si_stime=1930} ---
rt_sigreturn() = 23552
write(2, Killed\n, 7Killed
) = 7
read(10, , 8192) = 0
exit_group(137) = ?
+++ exited with 137 +++
I can't see anything odd in the log file and I've turned debugging on
in galaxy.ini. I'm at a bit of a loss. Does anyone know what might be
causing it?
Cheers,
- --
Dr. Martin Vickers
Data Manager/HPC Systems Administrator
Institute of Biological, Environmental and Rural Sciences
IBERS New Building
Aberystwyth University
w: http://www.martin-vickers.co.uk/
e: mj...@aber.ac.uk
t: 01970 62 2807
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iQEcBAEBAgAGBQJVp80YAAoJEHa0a8GkKQgIGlIH/1VfAPbs/5ApDBdyoOV5qf1y
oCOv93IojARyfI0ksSjF8NRNzw5fNp1R8AzZzomaR3SOUkBuZutre600sy0azTZw
E6gjxtMuvaMyEsOTXtToVarVJT0wTG8+5DJRIYLxtYZm7kvbZK0WuzrN2zDT6663
Rnm7zI/zBpTAyp6uXwgmz0x5gpH6KFwRcEHEbU3JWy6nj1zithJShwYPlBuhT5IB
OaPwOKflcZpZ8NBTEGsh038JrkU+eE50a9aEjQ2m/DpfM/TN9ujgEFm1dyy/iQS7
ewwQUpWJDkA/u0ZX602dsNdV2LvGuKVVMEHiQ25zaUQZ/iGTwKBQsFM2LlDybgA=
=jzYG
-END PGP SIGNATURE-
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Ipython behind apache proxy, firefox CORS error
Jelle and I have been debugging over IRC, crossposting here for awareness
until I can get proper fixes pushed all the right places.
Jelle, like I, have proper enterprise deployments. I.e. SSL, galaxy under
a proxy-prefix, etc.
galaxy.ini:
1. galaxy_infrastructure_web_port = 8090
2. dynamic_proxy_manage=True
3. dynamic_proxy_session_map=database/session_map.sqlite
4. dynamic_proxy_bind_port=8800
5. dynamic_proxy_bind_ip=0.0.0.0
6. dynamic_proxy_debug=True
7. dynamic_proxy_external_proxy=True
Apache conf needs to have special routes for the ipython GIE, I've added
this to my master GIE planning issue
https://github.com/galaxyproject/galaxy/issues/372.
1. RewriteEngine on
2. RewriteRule ^/galaxy-dev/ipython/(.*)
http://localhost:8800/galaxy-dev/ipython/$1 [P]
3.
4. Location /galaxy-dev/ipython/
5.ProxyPassReverse http://localhost:8800/galaxy-dev/ipython/
6. /Location
Now that all that is set up, until galaxy's interactive_environments.py can
be updated, you have to manually correct the URLs from mako:
--- a/config/plugins/interactive_environments/ipython/templates/ipython.mako
+++ b/config/plugins/interactive_environments/ipython/templates/ipython.mako
@@ -36,8 +36,8 @@ else:
## General IE specific
# Access URLs for the notebook from within galaxy.
-notebook_access_url =
ie_request.url_template('${PROXY_URL}/ipython/${PORT}/notebooks/ipython_galaxy_notebook.ipynb')
-notebook_login_url =
ie_request.url_template('${PROXY_URL}/ipython/${PORT}/login?next=%2Fipython%2F${PORT}%2Ftree')
+notebook_access_url =
ie_request.url_template('${PROXY_URL}/galaxy-dev/ipython/${PORT}/notebooks/ipython_galaxy_notebook.ipynb')
+notebook_login_url =
ie_request.url_template('${PROXY_URL}/galaxy-dev/ipython/${PORT}/login?next=%2Fipython%2F${PORT}%2Ftree')
With this, it's pretty close, however the containers aren't yet aware of
the new URL they're to be accessed under:
From 76bf20de305d64e544911a86ea5d0cb03e4281bd Mon Sep 17 00:00:00 2001
From: Eric Rasche e...@tamu.edu
Date: Thu, 16 Jul 2015 12:00:47 -0500
Subject: [PATCH] Use galaxy prefix to build a full URL
---
ipython_notebook_config.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ipython_notebook_config.py b/ipython_notebook_config.py
index 3d9780d..4ec4675 100644
--- a/ipython_notebook_config.py
+++ b/ipython_notebook_config.py
@@ -21,8 +21,9 @@ if os.environ.get('DOCKER_PORT', 'none') == 'none':
c.NotebookApp.base_url = '/ipython/'
c.NotebookApp.webapp_settings = {'static_url_prefix':
'/ipython/static/'}
else:
-c.NotebookApp.base_url = '/ipython/%s/' % os.environ['DOCKER_PORT']
-c.NotebookApp.webapp_settings = {'static_url_prefix':
'/ipython/%s/static/' % os.environ['DOCKER_PORT']}
+url_base = '%s/ipython/%s/' % (galaxy-dev, os.environ['DOCKER_PORT'])
+c.NotebookApp.base_url = url_base
+c.NotebookApp.webapp_settings = {'static_url_prefix': '%s/static/' %
(url_base, os.environ['DOCKER_PORT'])}
if os.environ.get('NOTEBOOK_PASSWORD', 'none') != 'none':
c.NotebookApp.password = os.environ['NOTEBOOK_PASSWORD']
--
2.3.5
With the above patch applied, and the container rebuilt (remember to
specify it in ipython.ini), everything *SHOULD* work.
This will all be corrected by the next Galaxy release so that containers
are automatically aware of proxies, and all of this is handled slightly
more sensibly.
Cheers,
Eric
2015-07-15 13:20 GMT-05:00 Eric Rasche e...@tamu.edu:
Hi jelle,
Replied to IRC but you disconnected.
- Do you have dynamic_proxy_external_proxy=True?
- You may need to set an Origin header, which is technically bad
practice, but since the user is validated by the galaxy cookie, it's a bit
more acceptable.
I'm on IRC for further debugging if need be.
Cheers,
Eric
2015-07-15 4:47 GMT-05:00 Jelle Scholtalbers j.scholtalb...@gmail.com:
Hi Björn, Eric, all,
I'm trying to get ipython running on our instance. Without the proxy,
e.g. http://myserver:8080 it works fine. However, with the proxy in
front (e.g. http://myserver/galaxy) I get this firefox error
11:28:37.793 Cross-Origin Request Blocked: The Same Origin Policy
disallows reading the remote resource at
http://gbcs-dev:8800/ipython/39958/login?next=%2Fipython%2F39958%2Ftree.
(Reason: CORS request failed).1 unknown
or on chrome xhr request cancelled.
Do you happen to know the correct apache settings to overcome this?
I tried a few things, but I ended up with ipython starting, but with a
message cannot connect to websocket.
- Jelle
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
--
Eric Rasche
Programmer II
Center
Re: [galaxy-dev] Slow repsonses viewing histories
Hi Nate, Problem solved (with one small exception) with much help from Marius. I followed his instructions to apply the three patches via mercurial: You can get the diff of a pull request by adding .diff, like so: https://patch-diff.githubusercontent.com/raw/galaxyproject/galaxy/pull/345.diff https://patch-diff.githubusercontent.com/raw/galaxyproject/galaxy/pull/416.diff https://patch-diff.githubusercontent.com/raw/galaxyproject/galaxy/pull/466.diff These should be the 3 pull requests for the issue you referenced. So you should be able to do curl https://patch-diff.githubusercontent.com/raw/galaxyproject/galaxy/pull/345.diff |patch -p1 and then the other 2. It's probably a good idea to do another branch for testing this, e.g. hg branch fix_metadata hg commit -m branch to test metadatafix I had to manually resolve one of the patches in lib/galaxy/tools/actions/metadata I also had to manually resolve that one as the patch for that file didn’t apply properly. I was then able to reset all metadata for the BAMs listed following the SQL search and hey presto history display back to normal speed :) The one issue I still have is that 9 of the offending BAMs are actually in a history that I deleted permanently by accident during the UI slow-response. So they are still listed in the SQL search. This doesn’t seem to be adversely affecting the speed but obviously I can’t reset their metadata now. Is this a problem? Thanks for the help, Rich On 16 Jul 2015, at 11:45, Poole, Richard r.po...@ucl.ac.ukmailto:r.po...@ucl.ac.uk wrote: Hi Nate, I have managed to update to the latest version of the default branch but I do not see the ‘max_metadate_value_size’ in my universe_wsgi.ini (this file was not changed during the update). Same thing if I use hg pull hg update stable or hg pull hg update release_15.05. Does this mean this change is not yet on mercurial and if so how can I pull this specific change (using curl?) to generate my own branch specific for the patch? Thanks, Richard On 15 Jul 2015, at 20:59, Richard Poole ucga...@live.ucl.ac.ukmailto:ucga...@live.ucl.ac.uk wrote: Just a little update - executed the SQL query and luckily only returned 20 BAM files - the most recently generated ones of course. Now makes sense this could well be the cause of the UI problem as my account became more and more unresponsive the more of these 20 BAM files I generated over the last week……….. Rich On 15 Jul 2015, at 20:38, Richard Poole ucga...@live.ucl.ac.ukmailto:ucga...@live.ucl.ac.uk wrote: Hi Nate, Ok - I can try this but I’m not an SQL database expert - far from it in fact. That query will just list ‘problematic’ datasets? I have a lot of histories with BAM files ;) Resetting the metadata needs to be done before this fix works? I ask because my history is so slow now as to be unusable…….or setting the cutoff allows Galaxy to be usable but it wipes out the metadata (which then needs resetting). I am still using universe_wsgi.ini not galaxy.ini and I don’t see the 'max_metadata_value_size’ in any section of my universe_wsgi_ini file - I guess because I’m not on latest update. I am actually not sure what version I am on as to fix an earlier issue with shared datasets (that wasn’t yet on mercurial) on the advice of a few folks I generated a branch specific for the patch using: hg branch fix_history_sharing curl https://github.com/galaxyproject/galaxy/commit/62772bc86e2504982f207a982542cbcc3faf0c65.diff|patch -p1 Also not being a huge mecurial expert I am a little unsure now how to switch back to stable branch correctly and pull the latest updates. Could you advise (sorry to be a noob)? Rich On 15 Jul 2015, at 20:22, Nate Coraor n...@bx.psu.edumailto:n...@bx.psu.edu wrote: Hi Richard, Unfortunately, you will need to reset metadata for any problematic datasets once you have updated to the latest version of 15.05 and set a cutoff value. You can find the datasets with the following SQL query in your database: select hda.idhttp://hda.id/, u.email, h.namehttp://h.name/, hda.hid, hda.namehttp://hda.name/, length(hda.metadata) from history_dataset_association hda join history h on hda.history_id=h.idhttp://h.id/ join galaxy_user u on h.user_id=u.idhttp://u.id/ where length(hda.metadata) 1048576 order by length(hda.metadata) desc; And you can reset metadata by clicking on the dataset's pencil icon in your history and clicking auto-detect. --nate On Wed, Jul 15, 2015 at 3:16 PM, Poole, Richard r.po...@ucl.ac.ukmailto:r.po...@ucl.ac.uk wrote: Hi Nate, I am indeed using later than 15.05………so I will try this fix next time I can restart the server and let you know. Richard On 15 Jul 2015, at 19:32, Nate Coraor n...@bx.psu.edumailto:n...@bx.psu.edu wrote: Hi Richard, By any chance, are you running Galaxy 15.05 or later? 15.05 includes new metadata for bam files that can cause UI performance problems with certain types of bam files. This can be limited with the
Re: [galaxy-dev] ./run.sh segfault
Hi Nate,
Thanks for the reply. In syslog I'm getting;
Jul 16 20:36:41 galaxy kernel: [ 117.123921] Out of memory: Kill process 1390
(python) score 986 or sacrifice child
Jul 16 20:36:41 galaxy kernel: [ 117.124087] Killed process 1390 (python)
total-vm:43496348kB, anon-rss:32611892kB, file-rss:1800kB
(END)
It's a 32GB VM. I could increase it but I wouldn't expect 32GB to be too
little. I've attached the full syslog.
Dr. Martin Vickers
Data Manager/HPC Systems Administrator
Institute of Biological, Environmental and Rural Sciences
IBERS New Building
Aberystwyth University
w: http://www.martin-vickers.co.uk/
e: mj...@aber.ac.uk
t: 01970 62 2807
From: Nate Coraor n...@bx.psu.edu
Sent: 16 July 2015 04:36 PM
To: Martin Vickers [mjv08]
Cc: galaxy-dev@lists.galaxyproject.org
Subject: Re: [galaxy-dev] ./run.sh segfault
Hi Martin,
Is there anything in the syslog?
--nate
On Thu, Jul 16, 2015 at 11:26 AM, Martin Vickers
mj...@aber.ac.ukmailto:mj...@aber.ac.uk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
I have a weird issue that's just cropped up. After a new install of
galaxy (checked out on Monday from github) on a ubuntu vm, using
postgres rather than sqlite as well as a few other production
recommendations, I started playing around with the Data Libraries
functionality. I linked a bunch of fastq.gz files into galaxy (around
150 in total) and everything was working fine. I went home and the
next day, it was down.
I tried to start it up as usual (using an init.d script), it worked
for less than a minute and then disappeared again. So I tried running
it as the galaxy user using ./run.sh and I get a seg fault;
Starting server in PID 23173.
serving on http://144.124.110.39:8080
Segmentation fault
Tried again with strace
Starting server in PID 23552.
serving on http://144.124.110.39:8080
[{WIFSIGNALED(s) WTERMSIG(s) == SIGKILL}], 0, NULL) = 23552
- --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=23552,
si_status=SIGKILL, si_utime=1590, si_stime=1930} ---
rt_sigreturn() = 23552
write(2, Killed\n, 7Killed
) = 7
read(10, , 8192) = 0
exit_group(137) = ?
+++ exited with 137 +++
I can't see anything odd in the log file and I've turned debugging on
in galaxy.ini. I'm at a bit of a loss. Does anyone know what might be
causing it?
Cheers,
- --
Dr. Martin Vickers
Data Manager/HPC Systems Administrator
Institute of Biological, Environmental and Rural Sciences
IBERS New Building
Aberystwyth University
w: http://www.martin-vickers.co.uk/
e: mj...@aber.ac.ukmailto:mj...@aber.ac.uk
t: 01970 62 2807
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iQEcBAEBAgAGBQJVp80YAAoJEHa0a8GkKQgIGlIH/1VfAPbs/5ApDBdyoOV5qf1y
oCOv93IojARyfI0ksSjF8NRNzw5fNp1R8AzZzomaR3SOUkBuZutre600sy0azTZw
E6gjxtMuvaMyEsOTXtToVarVJT0wTG8+5DJRIYLxtYZm7kvbZK0WuzrN2zDT6663
Rnm7zI/zBpTAyp6uXwgmz0x5gpH6KFwRcEHEbU3JWy6nj1zithJShwYPlBuhT5IB
OaPwOKflcZpZ8NBTEGsh038JrkU+eE50a9aEjQ2m/DpfM/TN9ujgEFm1dyy/iQS7
ewwQUpWJDkA/u0ZX602dsNdV2LvGuKVVMEHiQ25zaUQZ/iGTwKBQsFM2LlDybgA=
=jzYG
-END PGP SIGNATURE-
___
Please keep all replies on the list by using reply all
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
Jul 16 20:17:01 galaxy CRON[2435]: (root) CMD ( cd / run-parts --report
/etc/cron.hourly)
Jul 16 20:22:10 galaxy puppet-agent[2643]: Finished catalog run in 0.25 seconds
Jul 16 20:32:37 galaxy kernel: [121243.785394] init: tty4 main process (994)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.785744] init: tty5 main process (997)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.786083] init: tty2 main process (1003)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.786428] init: tty3 main process (1004)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.786787] init: tty6 main process (1006)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.787663] init: cron main process (1036)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.788318] init: irqbalance main process
(1069) killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.788853] init: hvc0 main process (1806)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.790003] init: tty1 main process (1810)
killed by TERM signal
Jul 16 20:32:37 galaxy kernel: [121243.790710] init: plymouth-upstart-bridge
main process (3302) terminated with status 1
Jul 16 20:32:37 galaxy kernel: [121243.790729] init: plymouth-upstart-bridge
main process ended, respawning
Jul 16 20:32:37 galaxy rsyslogd: [origin software=rsyslogd swVersion=7.4.4
x-pid=744 x-info=http://www.rsyslog.com;] exiting
