LPGhatguy / aftman

Aftman, the prodigal sequel to Foreman
MIT License
157 stars 16 forks source link

Ability to keep descendant processes running after aftman closes #39

Open Corecii opened 1 year ago

Corecii commented 1 year ago

The way Aftman puts processes into a job on Windows disallows all descendant processes from running after Aftman closes unless you do some really hacky stuff.

It is possible to allow job processes to break away from jobs without hacks: set the JOB_OBJECT_LIMIT_BREAKAWAY_OK limit on the job, then the child processes can break away if spawned with CREATE_BREAKAWAY_FROM_JOB.

This is almost straightforward: Rust already has a mechanism for setting creation flags like CREATE_BREAKAWAY_FROM_JOB. There's no existing API for setting job limits like JOB_OBJECT_LIMIT_BREAKAWAY_OK though, even in the command_group crate. The correct sequence for setting this limit looks like: create the job, set the limit, spawn the descendant processes. I feel like this would be a simple change to the command_group crate to support (or alternatively, a simple change to run the same code in Aftman instead).


I particularly need this for spawning Roblox Studio. Without this (or workarounds), Studio is closed as soon as the spawner is done. We are using this for a tool that downloads a copy of production and opens it as a local file to avoid mistakes that can happen when production is actually open.

This would also be applicable for any other launching-of-a-gui utility command.


As a workaround, the WMI Win32_Process.Create method just so happens to ignore jobs. I was having a lot of trouble calling this from Rust, so I ended up having Rust run a powershell snippet which spawns the process. How hacky!

To open a rbxl file, we do the following:

    powershell_script::run(&format!(
        r#"([WMICLASS]"win32_process").Create('explorer "{}"')"#,
        path.as_os_str().to_string_lossy()
    ))