#289 Bowtie hangs - specific situation related to VMs

v0.9.0
closed
Val
None
5
2014-01-30
2013-08-15
JustinNelligan
No

So I've been doing RNA-seq analysis using tophat on a Ubuntu virtual machine, using shared folders to hold the fastq files and the indexes.

I noticed that it was taking an unordinate amount of time at any step that would involve index building using bowtie-build if the said index was on the shared folder, but not the local virtual machine one. This involve transcriptome index building, which can be circumvented, but also splice junction index building, if the saving folder for the analysis happen to be on a shared drive.

Specifically, the process seem to hang at a bowtie --sam /indexOnTheVmFolder/indexName /dev/null, after the index was successfully built. Linux process reports 'rtR0SemEventMultiLnxWait.isra.2' as a waiting channel. If I replicate the same command piping to the screen, I get the output, but then it hangs at the end of the SAM header.

Obviously all of this can be circumvented by using the drive in the virtual machine, but you might want to find the cause of this in case it happens in other scenarios.

Latest versions of everything (samtools 0.1.19, bowtie 1.0.0, tophat 2.0.9). Tried recompiling without spinlock, same effect. This problem happened only upon upgrading versions of everything, so thus far I can't pinpoint what upgrade caused it, but it was definitely working with previous versions of bowtie/tophat. I'll investigate that.

Discussion

  • Val
    Val
    2013-08-15

    • assigned_to: Val
     
  • Val
    Val
    2013-08-15

    Hi Justin,

    Thank you for letting us know about this. I would like to try to reproduce this behavior though. When you say shared folders I assume you are talking about NFS. Can you tell me please what NFS version you are using and what are the mounting options for those shared directories?

    thanks,
    Val

     
  • JustinNelligan
    JustinNelligan
    2013-08-16

    Alright so I tested a few more things and I don't think it's bowtie's fault - it happens with earlier versions of bowtie and/or tophat, also with bowtie2. If I kill the job when it hangs, I get this traceback:

    Traceback (most recent call last):
    File "/home/imbeault/tophat-2.0.9.Linux_x86_64/tophat", line 4072, in <module>
    sys.exit(main())
    File "/home/imbeault/tophat-2.0.9.Linux_x86_64/tophat", line 4038, in main
    user_supplied_deletions)
    File "/home/imbeault/tophat-2.0.9.Linux_x86_64/tophat", line 3429, in spliced_alignment
    map2gtf(params, sam_header_filename, ref_fasta, left_reads, right_reads)
    File "/home/imbeault/tophat-2.0.9.Linux_x86_64/tophat", line 3287, in map2gtf
    transcriptome_header_filename = get_index_sam_header(params, m2g_bwt_idx)
    File "/home/imbeault/tophat-2.0.9.Linux_x86_64/tophat", line 1418, in get_index_sam_header
    stderr=open('/dev/null'))
    File "/usr/lib/python2.7/subprocess.py", line 493, in call
    return Popen(popenargs, kwargs).wait()
    File "/usr/lib/python2.7/subprocess.py", line 1281, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
    File "/usr/lib/python2.7/subprocess.py", line 478, in _eintr_retry_call
    return func(
    args)

    Right now I think Virtual Box way of sharing folders must have changed and is causing problems somehow, so for now I don't think bowtie is the real problem and its such an edge case that I'll just write on the VM for now. If I ever find anything else I'll update this but feel free to mark as closed :)

     
  • Val
    Val
    2014-01-30

    Thanks for letting us know about this issue related with Virtual Box.

    I will close this case now.

    Val

     
  • Val
    Val
    2014-01-30

    • status: open --> closed