Examining and/or modifying RNAStar script internals

,
1

I help maintain a local Galaxy server for a medical establishment.
When users try running RNAStar from Galaxy it fails. Note that it uses DRMAA to submit jobs to a Slurm cluster as the Galaxy user.
When I run the command manually with the same data, it succeeds, as long as I specify a sufficient amount of sorting memory AND tell Slurm how much memory to use.

Is there a way to examine/modify the bits that put together RNAStar scripts? Is there a way to see the actual commands used (i.e., with the calculated parameters for things like memory for sorting)?
Also, the user who ran the job (which failed) through Galaxy stated there was no output from the job. Was she mistaken? Is there a way to see job output? That can be crucial to solving problems.

1 Like
2

Welcome, @caldodge

Please see, in no particular order:

  1. The admin tutorials here cover job control, including resource parameters that can be tuned. https://training.galaxyproject.org/training-material/topics/admin/

  2. Those materials may reference the primary admin docs, but these can also be used directly: https://docs.galaxyproject.org/

  1. Sometimes partial outputs can be seen by users under the Dataset Details page, or by clicking on the eye icon in a red dataset output. That’s the same place where the job logs are located in the GUI, along with paths to/from real datasets and other keys (job api ID, etc). Admin server logs would have more information.

  2. This is a popular add-on utility for admins, for reasons just like yours aka “what is going on??” or running tests that you can track/follow/inspect during runtime to see what was produced at that level (ssh or similar, not GUI). :slight_smile: GitHub - galaxyproject/gxadmin: Handy command line utility for Galaxy administrators 🚀

  3. And, installed tools sometimes have settings in the wrapper that matter at runtime. You could adjust those in your copy. Search with tool names directly, or click to the “see in Toolshed” from the application: https://toolshed.g2.bx.psu.edu/ → has links to the Galaxy development repository and to resources from the original underlying tool author. A lot of that content is being synced up between public Galaxy servers as the optimal resources per tool (by itself, or based on features of the inputs like size). You might want to assign more, but learning the practical minimums – and where those are specified per-tool so you can adjust – seems relevant here.

  4. Finally, there are examples of job/tool configuration files availably publicly for UseGalaxy.org in these repos that you could model from. The tutorials will explain what to look at. It is more than just the job_conf.yml or job_conf.ini.

Let’s start there. This might involve just a few lines of adjustments.

If you need more help, please share more details. That could include parts of logs or configuration files, and the version of Galaxy you are running (and any special config, like your cluster situation). Please remember to redact anything private like important keys …