application tries to performa administrative action (create folder in root filesystem)

[GitterRook]

Version : 4.3.1

Use truvari version to get the version you're using. If the version ends in *-dev, report the git show-ref --hash HEAD of the repository you're working on.

Describe the bug :
running the software results in
/APPLICATIONPATH/bin/python3.11: Permission denied: Unknown error 1469086800
the users have full read and execute permission

with strace we notice the application tries to create a folder on the root file system. looks like a / is missing
mkdir("/tmpIkFtle", 0700) = -1 EACCES (Permission denied)

FYI users does not have administrator permission on our shared HPC setup

A clear and concise description of what the bug is.

To Reproduce :
Steps/Commands to reproduce the behavior with stdout/stderr log lines when reasonable/necessary.
truvari bench -b truth.vcf.gz -c compare.vcf.gz -o output --pctseq 0 --typeignore --includebed tier1.bed

Expected behavior :
A clear and concise description of what you expected to happen.
the application not to fail. we have earlier releases which works fine. the problem has started with this newest release

Example Data :
If applicable/possible, add example data to help recreate your problem.

Additional context :
Add any other context about the problem here.

[ACEnglish]

See #229 There's a fix in the queue that'll let Truvari help prevent it from happening, but the user-side solution is to ensure that the $TMPDIR environment variable is set.

[GitterRook]

Thanks for reply. sorry i missed the workaround
We will configure env var for this module

I still believe you should look at "your" code so this should not be necessary.
It simply look like the tmp string or it is called in the source code is missing a "/"

mkdir("/tmpIkFtle", 0700) = -1 EACCES (Permission denied)

/tmpIkFtle -> /tmp/IkFtle
IkFtle is the random generated application temporary folder

[ACEnglish]

I appreciate the extra information. But looking into it I still don't have a full truvari side fix.

There's only two places inside truvari's core code where a directory is made and they're both based on user parameters. The issue lies somewhere inside of our call to bcftools.sort This command will make temporary files with prefixes of tmp, even when the $TMPDIR is set (e.g. my system just made tmpht8ywa8o).

In response to the last ticket on this issue, I changed the call to bcftools.sort, so that it is given tempfile.gettempdir() (line) which should resolve so something reasonable (details) But doesn't really help for as we're still seeing the problems.

As an example, I have a python script that simply runs:

import truvari
truvari.compress_index_vcf("a.big.vcf")

And when I run it with a TMPDIR set to e.g. /scratch/space/tmp, it works. When I run it without a TMPDIR (unset TMPDIR), it crashes

python: Permission denied: Unknown error 43908272

And, to your point, when I unset TMPDIR and update the compress_index_vcf function to add a / to tempfile.gettempdir() if its missing, we get a new error that:

pysam.utils.SamtoolsError: 'bcftools returned with error -1: stdout=, stderr=Writing to /tmp/Pd0UAi\n[buf_flush] Error: cannot write to /tmp/Pd0UAi/00001.bcf\nCleaning\n'

And if I run it with export TMPDIR=/tmp (what tempfile.gettempdir() returns when TMPDIR is unset) or even export TMPDIR=/tmp/, I get

python: Permission denied: Unknown error 26725664

This last test case is extra frustrating because I have read/write permissions for all of /tmp but bcftools still messes it up.
So I've looked into it and tried to figure out how truvari can solve the problem. But the answer seems to be that not setting a TMPDIR and defaulting to /tmp doesn't work with pysam's bcftools sort dispatch.

[ACEnglish]

Okay, so rubber ducking in the above comment got me thinking... if bcftools.sort is having a problem with /tmp, and I know that I can write to /tmp, what happens if I give bcftools a sub-directory e.g. /tmp/abcd. Turns out, that will fix the problem. Fix slated for release in v5.0 and available now in develop.

See 04d5feb

Thanks for the help!

[GitterRook]

Thanks for followup.

I am sorry if it sounded like i dont appreciate your work with this application. I totally respect your skills and work. I am not a hardcore developer.
I just observe and in my ignorance I thought it was a simple fix. it just looked funny how the folder created was created in Root file system and was a mix of a known temporary folder and a "application" generated (sub) folder.

Keep up the good work.