Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit shutdown behavior of the emulators #3578

Open
samtstern opened this issue Jul 16, 2021 · 11 comments
Open

Revisit shutdown behavior of the emulators #3578

samtstern opened this issue Jul 16, 2021 · 11 comments

Comments

@samtstern
Copy link
Contributor

samtstern commented Jul 16, 2021

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?"

@samtstern samtstern added emulator-suite polish Small feature requests labels Jul 16, 2021
@akauppi
Copy link

akauppi commented Jul 19, 2021

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
Copy link

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

@ftzi
Copy link

ftzi commented Oct 9, 2021

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
Copy link

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
Copy link

akauppi commented Oct 25, 2021

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
Copy link

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
Copy link
Member

@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
Copy link

+1

@Bullfrog1234
Copy link

+1

1 similar comment
@mikila85
Copy link

+1

@RobSteward
Copy link

RobSteward commented Aug 26, 2024

+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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests