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.

[Yura52]

@wolfv Hi! I have just noticed that the aforementioned pixi_trampoline crate is now gone or moved somewhere else. This makes me wonder if I should expect any improvements regarding the issue, i.e. can I expect that fish installed with pixi global is now as stable as fish installed with apt-get? Unfortunately, it is tricky to test this myself, because the issue was happening only on a server shared with many people, and triggering the issue means causing troubles for many people.

[Yura52]

@wolfv Hi! No urgency at all, but the question is still relevant to me, specifically this part:

can I expect that fish installed with pixi global is now as stable as fish installed with apt-get?

To add more context, I am going to introduce Pixi to more people around me as a way to install global tools, and I am trying to understand whether I should position as a way to install only "simple" global tools (e.g. fd, ripgrep, etc.), or it is now stable enough to install all kinds of tools, including long-running binaries like fish.

[Yura52]

@ruben-arts Hi! By any chance, are you aware of any updates relevant to my question?

[wolfv]

The source code for the trampoline is here: https://github.com/prefix-dev/pixi/tree/main/trampoline

If I remember correctly, we just exec the process from the trampoline (which should replace the parent with the child).

[Yura52]

@wolfv Thanks! Do you think that the custom Ctrl+C handler in the trampoline can be the root cause of the influx of zombie processes if I use Ctrl+C from time to time as described here?