For what it's worth, I ran into an issue with the use of /tmp as
well. When merging a lot of BAM files, /tmp filled up and the merge
failed. To make matters worse, since STDERR is redirected and the
exit status of java is not checked, the item in the Galaxy history
appeared OK. Though examination of the .log file revealed the
issue, users weren't aware of the problem right away, causing
further confusion. To get around this, I implemented two fixes:
1 - Wrapper for sam_merge2 very similar to hide_stderr.py used by
the ncbi_blast_plus tools. I did have to "hack" it a bit, however,
since when I output the captured stderr, galaxy would hang if it was
too large. My "fix" was to output the first and last 7500
characters of stderr (truncating the middle). Now when the merge
fails, users see a failure in Galaxy (red history item).
2 - Looking at other Picard tools, it seems that at least some of
them explicitly set TMP_DIR to $__new_files_directory__, which in
this case seemed appropriate, at least for my use case. So I added
that simple change to the sam_merge.xml command line.
I'm open to better solutions if people see issues with these, but I
would suggest that Galaxy be updated to include fixes for these
issues since it seems others are likely to run into these problems.
If people generally agree I'd be happy to provide create tickets
and/or provide changesets or whatever the Galaxy maintainers would
prefer.