Revisit shutdown behavior of the emulators

[samtstern]

Currently we do this for the emulators:

• One Ctrl+C (SIGINT) --> clean shutdown
• Two or more Ctrl+C (SIGINT) separated by a human interval --> immediate shutdown

We should probably never shut down dirty on Ctrl+SIGINT, it seems that many tools and terminal emulators pass SIGINT many times which causes a dirty shutdowns. Dirty shutdowns can lead to corrupted exports, blocked ports, etc and other things which are much harder to clean up than a runaway process.

We could instead do something like raise a prompt like "You seem to be slamming Ctrl+C friend, would you like to force quit?"

[akauppi]

I'm eager to see if this would help with a problem I have with npm, concurrently, Docker and Firebase.

In short, concurrently is known to be sending signals multiple times, on an Alpine image, to kill processes. The thinking goes, with the heuristic behaviour Sam explains above, that this could cause non-clean exits from Firebase Emulators.

This, in turn, leaves ports dangling when the whole Docker process is killed, which is slightly surprising, to say the least.

There are multiple places this snowball effect could be avoided. The change in Firebase Emulators is one of them.

If this gets to a PR, I'm happy to test that in advance of actual release, to provide feedback whether it helps in my situation.

[annzimmer]

I've filed this bug internally (b/194384884) for more investigation/tracking.

[ftzi]

In short, concurrently is known to be sending signals multiple times, on an Alpine image, to kill processes. The thinking goes, with the heuristic behaviour Sam explains above, that this could cause non-clean exits from Firebase Emulators.

I just changed from concurrently to npm-run-all, and my Ctrl+C double SIGINT is gone; I can now export and import emulator data.

[amkoehler]

I just changed from concurrently to npm-run-all, and my Ctrl+C double SIGINT is gone; I can now export and import emulator data.

I tested this and the emulator processes still aren't exiting properly. After Ctrl+C all the emulator ports are still in use.

[akauppi]

Since July (comment above) I’ve gotten the Docker Compose solution to be pretty sweet. Am happy to share it and help if someone wants to take that route. As I wrote:

There are multiple places this snowball effect could be avoided.

One of them is by using the emulators via Docker. This allows sandboxing them at large, which I find useful.

[MatthewFallon]

Wanted to ask about possibilities for this too. Forcing clean shutdown would be great, but what can be a back up if that fails or if a process sends a SIGTERM or SIGKILL, potentially with IDE tooling or with other runners?

Is there a potential for each of the external processes to at the least run a health check of some sort against the central server program started by emulators:start? (i.e. if the terminal force quit unexpectedly, after a time interval each of the services would perform a health check and automatically shutdown if the central program was not running)

I figure something like this may still have data loss from the exports, but at least it would help with cleaning up disconnected processes and freeing up blocked ports which in general is the main pain point for using the emulator and the reason most have had to swap to a container like docker to isolate the environment which adds its own struggles/complications then.

[yuchenshi]

@MatthewFallon these are great ideas and we're tracking them in an internal bug now. We are unable to promise any timeline for this, but if others also have this request, adding a +1 on this issue can help us prioritize adding this to the roadmap.

(Googler-only internal tracking bug: b/217243556)

[lucaslenz]

+1

[Bullfrog1234]

+1

[mikila85]

+1

[robin-scharf]

+1 (I run into this when I run firestore)

firebase emulators:start --only auth,hosting,functions,storage --> Runs without opening Java command line window firebase emulators:start --only auth,hosting,functions,storage,firestore --> Runs with opening Java command line window

[mdulc928]

+1

[mdulc928]

I suppose if you don't mind, you can always run the firestore emulator separately since it is only the UI that's broken. The port doesn't change, thankfully.

For the firebase-tools devs, it would make sense that any emulator UI instance can detect when a firestore instance is up since the uri is still the same.

Either way, thanks for the great product, y'all ❤ , keep it up!

(Yes, there are hair pulling moments, but the fact is it works and it works really well for you skeptical folks)

[JamesJoyceGit]

This is still happening to me! When I include "firestore" in the emulator:start - it spawns a new window to run it, alongside the existing emulator window...

My versions:

• "firebase-admin": "^12.6.0"
• "firebase-functions": "^6.0.1",

And firebase tools v14.16.0