Roblox / foreman

Toolchain manager for Roblox projects

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Foreman does not properly kill long-running processes

filiptibell opened this issue · comments

Spawning a long running process in the terminal such as rojo serve and hitting Ctrl+C does not properly kill the process, it just leaves it hanging. This means that commands that bind to an address, such as the above, will not work at all after the first run.
I'm getting this issue using foreman v1.0.3 and macOS 12.3 on an M1 MacBook Pro 14''.

I was told that applying a patch similar to this one (LPGhatguy/aftman@1842a95) would solve the issue, however it seems like foreman already uses CommandGroup (since 7a037d9) so this might be a separate issue 🤔

A workaround for now is to use something like Activity Monitor, find and force-kill the spawned process, or to reboot.

Edit:

I had a suspicion that it might have been because of my shell (nushell) so I went and checked bash, zsh, fish, and they all behave the same. I also tried different terminals with each: VSCode built-in, hyper, terminal.app, same behavior for all there as well.

+1 on the issue here.

Running Zorin OS 6, (based on Ubuntu 20.04) so I have bash as my shell. Ctrl + C does not kill the process at all, and this only happens with rojo installed via foreman. I can easily kill a Rust program through SigInt but it does not work with Rojo. My Foreman version is v1.0.3, bash version version 5.0.17(1)-release (x86_64-pc-linux-gnu).

Running ss -tunlp | grep 34872 after running rojo serve shows that the process was not ended:

image

This is a pretty frustrating bug as I have multiple different *.project.json files and often need to stop serving once so I can then serve with a different project.json.

It's pretty strange bug here and I assume it's because of multi-layer process running, not too sure though (not an expert to say the least).

I get the same issue as well, and I'm using bash. After running rojo serve I have to run pkill rojo to be able to run the command again.

Turns out this is simply due to how unix-like OSes handle subprocesses, the issue has been solved in LPGhatguy/aftman@d3f8d1f and foreman would need to do something similar.