Hey all, I'm currently trying to make a version of taxprofiler with the new "k2" wrapper of Kraken2 to use the --use-daemon functionality. The thing I'm struggling with is that k2 classify creates a file with the process ID "/tmp/classify.pid" to the daemon and the path is hardcoded. Whenever I launch k2 from the taxprofiler pipeline (with -profile conda) this file is not created. I'm guessing that it must be some permissions issue in the configuration of nf-core pipelines, that processes don't have permission to write outside of defined directories. But I cannot figure out where this is set or how to change it. I also tried this with a very simple nextflow pipeline and there it works. Would be very grateful if anybody has an idea, thanks a lot.

Hi @Laurenz Holcik! I also saw your github issue, sorry for the slow reply - Lili is on holiday and I'm only on half days because of sick children/school closures. I'm curious to see about your

--use-daemon

functionality, whihc I had not heard of as it sound svery nice - is this similar to KrakenUniq's 'preloaded' option? To my knowledge (and a quick code search now), the nf-core pipelines do not touch anything to do with

tmp/

directories by default. Do you by any chance have your 'simple' pipeline available so we can compare? As a general rule you can control the location of

/tmp

using the

scratch

directoive: https://nextflow.io/docs/latest/reference/process.html#scratch When you say hardcoded, do you mean literally the string

/tmp/classify.pid

, or that it takes

$TMPDIR

?

Hi @James Fellows Yates thanks for your fast reply! I don't think it's the same as the

--preload

function, loading the entire database into memory kraken2 does by default. Instead, when you're running kraken2 several times, it loads the database into memory (which takes long), then classifies reads of a sample and then would do the same all over again for the next sample. With the

--use-daemon

option, the database is kept loaded in memory in the background so when kraken2 is run again on the next sample it can skip the step of loading it into memory. The issue is then how to tell the next kraken2 process how to find the daemon and how the k2 developers solved this is apparently that they just create a file

/tmp/classify.pid

with the process ID - and yes this is really hardcoded in the C++ code of kraken2 (I opened a request on their gh to make this path a parameter). This is how I have adapted the KRAKEN2_KRAKEN2 process of the taxprofiler pipeline: https://github.com/Laurenz0908/taxprofiler/blob/master/modules/nf-core/kraken2/kraken2/main.nf And this is how my test script looks like:

process write_file {

script:

"""

k2 classify \\

--db /data/x1hbrnas4/big_db/kraken2_gtdb_226 \\

--use-daemon \\

/dev/null > /dev/null

"""

}

workflow {

write_file()

}

The test script works, the taxprofiler doesn't. I think implementing this as a general feature for the pipeline will be rather difficult because of the shared use of the daemon, this would go against the process isolation principles of nextflow and hard to implement on a HPC cluster. But I would think that at least on a local executor without containers there should be a way... EDIT: As you can see in the KRAKEN2_KRAKEN2 process I also added

touch /tmp/test_nf_core.txt

to see wether the process can write to

/tmp

and this file is also not created. But maybe this is some issue with my server, I will also try it on my laptop now.

I think implementing this as a general feature for the pipeline will be rather difficult because of the shared use of the daemon, this would go against the process isolation principles of nextflow and hard to implement on a HPC cluster.

Not necessarily, I think this should be a useful functionality we could actually implement - as you said database loading is annoying! We just gather multiple FASTQ files into a single process, and loop through them within the process using the same Kraken2 command that has

--use-daemon

That's a good point, if we actually gather the fastq files of multiple samples and pass them all to one kraken2 process then we don't need the

--use-daemon

flag. Kraken2 will then do this automatically to load it once for all samples, maybe this is the easier way to go. For my taxprofiler, I don't get an error at all. Kraken2 looks for the

/tmp/classify.pid

file with a loop and this just goes on indefinitely. So no error, process just never finishes (I guess nextflow timeout at some point). And yeah thank I did check

.command.run

and I saw that it creates a

tmp

directory for the process withing my

/tmp/

directory, however this does not affect

kraken2

because it doesn't take any environment variables and really just hardcoded the path.

1. I thought Kraken2 you can only run one sample at a time? 🤔 . Looking at the changelog the system seems ot be very similar to the KrakenUniq system (https://github.com/DerrickWood/kraken2/releases/tag/v2.1.5) 2/3. That's very odd.... what if you set the

scratch =

varible to

/tmp

anyway... I don't see how a Nextflow process can isolate that location necessarily 🤔

1. Ah sorry, you are right! 2. Okay then maybe this is really some issue with my system. I will try a bit more and get back to you, thanks a lot

I can try and test this at some point in december if you don't find a way around this

Thanks I'll let you know, and yess good point I'll ask this in a more general setting. I also think that for containers this will be difficult, and even more so for running on a cluster with multiple nodes.

Yeah... the multiple nodes is why I mention collecting all the files into a batch and looping through as then we don't have to suffer form that so much

Hey hey! Sorry I took so long, was quite busy with other projects. Anyways, I figured out why this wasn't working for me in the beginning: was just the version the nf-core/kraken2 module uses. I created a container with the latest version and now it works. So I have now implemented a batched processing of samples for kraken2 similar to what is done for krakenuniq. Is this still of interest?

Yup I think so! Please make a new module on nf-core/modules first and then we think about how to implement it in the pipeline 🙂

Ok will do :)

Depending on how you've made it, you may want to make a parallel module to th existing kraken2/kraken2 rather updating the existing one (if that wasn't obviosu)

Just curious, but has this moved forward? We have been skipping Kraken2 profiling on larger sequencing runs primarily due to the extensive time in loading the database per sample and have been running these using

--use-daemon

separately for a bit. I’d be happy to help if @Laurenz Holcik is okay with this.

No, it's sort of low priority for the main team, so go ahead!