feat: add a `detach` mode to the CLI #3568

jeffsmale90 · 2022-08-22T07:19:10Z

Do you need to detach? Do you need to do it now?

It can be annoying needing an extra terminal open just to run Ganache. This becomes super annoying when you want to have different instances and flavors of Ganache running at the same time.

Enter: Detach mode.

Start Ganache with the --detach flag, and it'll return to the console as soon as Ganache is ready to receive requests (writing the name of the instance to stdout).

ganache instances list will show you all of the instances of Ganache running in Detach mode, and you can stop them with ganache instances stop <name>.

┌───────┬─────────────────────────┬──────────┬─────────┬────────────────┬────────┐
│   PID │ Name                    │ Flavor   │ Version │ Host           │ Uptime │
├───────┼─────────────────────────┼──────────┼─────────┼────────────────┼────────┤
│ 12182 │ salted_caramel_ganache  │ ethereum │ 7.6.0   │ 127.0.0.1:8545 │ 2m 46s │
├───────┼─────────────────────────┼──────────┼─────────┼────────────────┼────────┤
│ 53184 │ candied_caramel_truffle │ ethereum │ 7.6.0   │ 127.0.0.1:8545 │ 2m 56s │
└───────┴─────────────────────────┴──────────┴─────────┴────────────────┴────────┘

With the following command, you can start Ganache, run your tests, and stop Ganache when you are finished.

GANACHE=$(ganache --detach) && npm run test; ganache instances stop $GANACHE

Or if you are running PowerShell on Windows, you can do:

$GANACHE=ganache --detach; npm run test; ganache instances stop $GANACHE

Fixes: #1001

…up as a background process

src/packages/cli/src/args.ts

jeffsmale90 · 2022-08-24T03:26:57Z

I looked into different ways to test this, and unfortunately came up empty.

I think it would be reasonable to test the cli via child_process.fork to execute the cli with given args. We can hang onto the ChildProcess instance, and listen to the close event after calling kill.

Unfortunately this becomes difficult with --detach. We can listen to the PID of the grandchild process via stdout, but we don't have a reasonable way to ensure that it shuts down cleanly. We would call kill(), wait an arbitrary length of time, cross our fingers and toes, and hope that it succeeds.

There's some workarounds I've found in unmaintained projects, where they spawn the ps command to check whether the process exists, and poll to wait for it to not exist, but I'm not comfortable with that approach, given the inconsistency across different platforms.

Keen to hear people's thoughts.

… (but don't show that in the help, because it's ugly)

jeffsmale90 · 2022-08-25T07:51:29Z

I've manually validated this on Mac, Ubuntu, and Windows 🎉

tenthirtyone · 2022-08-25T09:38:33Z

IIRC a .service file lets systemd run Node apps as a background process that lives inside it's own session and you can control it with systemctl.

I have no idea how that would translate to other operating systems or how npm would install a .service file into /var or /etc/systemd without some sort of hacky script and root permission.

If I understand, there is no way to stop the background process without killing the PID directly. It would be awesome if the system-level tools could manage that - it would avoid the polling.

Forever-js used to be the way to keep node going in the background. I believe they do something similar but start a worker that runs in the background, listens to a socket for communication from the cli and stores the PID of the child process somewhere. So you are in good company there.

src/packages/cli/src/args.ts

src/packages/cli/src/cli.ts

src/packages/cli/tests/args.test.ts

davidmurdoch · 2022-08-25T19:03:13Z

Is it typical for a detach mode to return the PID and only the PID? What other tools operate this way?
If that is typical behavior, I think i'm 👌 with shipping this without additional measures to track the instance. I'm sure we'll get users asking how to kill or get the process back, so maybe we'll figure out the best way of implementing some sort of re-connection API or instance-management from user feedback.

Tracking the PIDs ✨somewhere✨, as @tenthirtyone suggested, sounds reasonable for a follow up PR. IN the future we could have detached child open a socket (don't know if there is a way to reconnect to the original IPC socket) to allow for new connections to communicate with the process, then we could do things like ganache --attach <PID>.

Oh, one question. Should We pipe stdout somewhere else by default in this initial release, or should we let just let it get directed into the blackhole (/dev/null) until a user asks for a way to access the logs?

Last note: for the release notes description, can you also provide a Windows (either cmd.exe or Powershell) example, if there is reasonable equivalent?

…ch pid list.

…tance files if the process no longer exists.

src/packages/cli/src/process-name.ts

…tance data file to JSON format.