For me

Could you maybe check this?

Run a remote task with trains agent that would create inside another task that would again run remotely as well and check the permissions of the second task created file?

So I'd guess they would inherit my user as well

It what it does to my understanding

You can try copying all the contents of requirements.txt to the installed packages tab in the trains dashboard of your experiment (in the UI)

I understand how this is problematic. This might require more thinking if you guys wish to support this.

otherwise if you empty the installed packages and the requirements.txt is in one of the parents folder of the files that ran trains should detect it automatically

If I'd be exact that's a trains agent task that creates in a new subprocess another trains agent task

Well the original task is run with my user

So what can I do?

Changing the mountpoint for the agent is not possible

I will open one

Brutal sudo reboot, the agent is not up anymore

in the file's name

Oh

Yep. Works as you said.

And how can I tell which TRAINS_WORKER_ID I'm using?

in /tmp/.trainsagent_5031_f4iwisna.tmp
For example

Hmm
AttributeError: 'Task' object has no attribute 'tags'

I see, I'll try that

Nope, only its name

Actually the 5031 is the PID.

How can I tell what's the temp folder path?

Will try, thanks

By the way, what about enabling closing workers from the UI? 🙂

Let me check this out

Nope, I've run them with the command I've written here

I've ran this 8 times:
trains-agent --config-file /opt/trains/trains.conf daemon --detached --cpu-only --queue important_cpu_queue cpu_queueThe version is 0.16.2rc0 (a version Mushik gave me that supports local conda env)

SuccessfulKoala55 I found the temp files, they contain the supposedly worker id, which seems just fine