I'm running into an issue since working with the d...
# mag
j
I'm running into an issue since working with the dev commit 56a0eb3 RENAME_PREDASTOOL processes fail with exit code 126:
Copy code
cat /scratch/ronj2303/PROVID-LD/work/7a/5dd9b1c656f518ff3f0386604f754c/.command.log
env: 'singularity': Input/output error
cp: cannot stat '.command.trace': No such file or directory
is this something you've encountered/fixed in your later PRs ? I'm not sure how to debug this. I'm running coassembly with profile singularity but it's my first time getting this far so I'm not sure if it's a new bug or something else. I can open an issue if you prefer, just wasnt sure since this is not the main release
d
Hey @Jonathan Rondeau-Leclaire. That's a bit strage. Does
.command.err
show something else?
How does your
.command.sh
looks like?
For reference, I did run DAS Tool in my benchmark run and didn't have any issues. Only issue was with the following step (
DASTOOL_FASTATOCONTIG2BIN
), but more a performance improvement than a fix: github.com/nf-core/mag/pull/1071
j
nothing else in .err other than
Copy code
env: 'singularity': Input/output error
attaching the command.sh
strangely, I resumed the run about an hour ago and SEQKIT_STATS and GUNZIP_BINS processed are not cached, yet SPLIT_FASTA is. Not sure if it's related, but it's certainly not what I would expect, given that it was submitting RENAME_PREDASTOOL jobs in the previous run and I haven't touched anything since.
d
Did you try
cache = 'lenient'
? Maybe it something about the copy of the files to the scratch
j
I remember trying this before when we discussed it, but it told me this was unknown parameter so I had removed it. Are you saying I should try it, or remove it if I have it? currently I don't.
d
It's not a parameter, it's a process config. In your
nextflow.config
in the execution directory, add
Copy code
process {
    cache = 'lenient'
}
j
yes exactly. I'll try it again, maybe I had a typo.
oh adding this makes me start the entire pipeline over, I'll try to avoid it even if it means rerunning these few steps every time...
d
Oh, that's bad.
j
I'll try to reproduce the PREDASTOOL process fail, maybe it was a one-time bug with slurm, no idea... I'll keep you posted
iirc i had several runs of this process who did succeed, I can only find 4 that had errors in my work/