What are the global binaries in .pixi/bin ?

[Yura52]

I am debugging a weird issue that can be related to pixi. On my system (Ubuntu 18), over time, there are more and more zombie fish processes until they are explicitly stopped. fish is installed with pixi global and is launched with ./.pixi/bin/fish. I wonder if there is any difference between running ./.pixi/bin/fish and ./.pixi/envs/fish/bin/fish. One of my hypothesis is that specifically ./.pixi/bin/fish is the reason behind the zombie processes, but I am not sure. And generally, I wonder what is the nature of the binaries in .pixi/bin?

[wolfv]

Hi @Yura52 - they are simple binaries that invoke the fish process, but inject some "activation" variables (e.g. the PATH will have the CONDA environment injected, and so on.

The source code can be found here: https://github.com/prefix-dev/pixi/tree/main/crates/pixi_trampoline

On Unix we are using cmd.exec() which should replace the "trampoline" process with the process that is being launched.

[wolfv]

Please let us know if you find out anything!

[wolfv]

We should potentially remove the CTRL C signal handler from the trampoline because exec() should replace the current running process completely anyways.

[Yura52]

@wolfv Thanks for the prompt reply! Another thing that I have just realised after your comments is that, from time to time, I run things like this:

fish my_commands.fish

where fish is the pixi-global fish, as described in the initial post, and my_commands.fish contains many pixi run commands like this:

# my_commands.fish
pixi run python my_script.py ...
pixi run python my_script.py ...
pixi run python my_script.py ...
...

And sometimes, I do Ctrl+C to interrupt the currently running pixi run python ... command from the my_commands.fish file.

Anyway, all the above should be considered as preliminary observations. I will share if I find the root cause of the issue.