Never saw such errors before

Sounds interesting. In that case, how could I configure the agent to use such user?

Sure That's a really good question I am not sure how to answer. I know there is the problem of visualizing '{}' and visualizing {}. Maybe a bolded {} like this: {} ? or like this {} ? to emphasize the difference?

(And God knows I've seen things)

It happened again lately and I got:
File "/Remote/shared/conda_envs/tf14_tp099/lib/python3.6/site-packages/trains/backend_interface/util.py", line 76, in get_single_result
log = get_logger()
File "/Remote/shared/conda_envs/tf14_tp099/lib/python3.6/site-packages/trains/debugging/log.py", line 111, in get_logger
path = path or os.path.abspath((inspect.stack()[1])[1])
File "/Remote/shared/conda_envs/tf14_tp099/lib/python3.6/inspect.py", line 1494, in stack
return getouterframes(sys._getframe(1),...

Well nothing special, only says it's nfs version 3

mountpoint -q A && echo "" || mount B A

@<1523701087100473344:profile|SuccessfulKoala55> I'll try and update

I expected an exact match for the name

task.connect({'a':{},'b':'moshe'}, name='Train Data Params'))how this would then be appeared in the UI? (assume I don't want to update said empty dict for the moment)

Seems so, I'll put it my IT group into it, thanks for the hint!

Usually it's not an empty dict, it's optional additional keyword arguments. But it can also be empty if there is no optional keyword required.

ENV variables are the same but a KRB5CCNAME that appears in a working machine and does not in a non-worker machine, could this be it?

or they behave, as expected, via exact matching

No, I meant, are the tags behaving in this regex manner as well?

Also, could there be an "and" logic implemented in the task_filter argument for Task.get_tasks? currently it only supports "or" logic

More advanced search is great, but please try to include "and" behavior between multiple options as well (for example, "and" logic on multiple tags)

It seems treating this like a regex solved the issue. Again, I am not sure why partial matching is the default behavior.
And again, please oh lord, please, allow for and logic in this function. This would ease up computations a bunch (I filter on multiple tags and doing it one tag by one currently)

Problem is obviously the names won't match

If you want me to run some tests or some code to give you additional info, I sure can @<1523701070390366208:profile|CostlyOstrich36>

I see. Let me try that and get back to you

What specifically? they are sitting in the same VPN network as far as I know and as said before I can ping from one server to another

Sure I do since I can connect to it with my other agents

AgitatedDove14 , are there any more fields in this function with partial matching? for example project? tags?

Hi AgitatedDove14 ,
How could this be used in case of multiple configurations per task? How can I name such configuration?
Also this is sadly much less readable.
Would I be able to add customized columns like I am able to in task.connect ? Same question applies for parallel coordinates and all kinds of comparisons

If that's so, why would root cause the user to become nobody with group nogroup?

Sadly, I don't know. It started happening randomly to me as I used Task.get_tasks() frequently. the call to call_logger makes it all go wrong. I'd suggest trying to call it from several stack traces (i.e from inside different functions, that call other functions from one file or another, etc..)

Okay, another suggestion, simply record the type of each argument when you store it, and keep it in the database, unbeknownst to the user, what do you say?

Hahaha, you got me confused

Hmm, could this happen because I bring the agent up through crontab on reboot then? (with sudo crontab -e)