I use Jenkins + Systemd to build and run my production application. Whenever systemd attempts to shutdown the app (so that it can deploy a new version) it always times out and the app is abruptly killed instead of going through any sort of shutdown procedure. I don’t see anything in the documentation about shutting down a meteor app that isn’t deployed via docker.
What should I do? I want to make sure I finish executing methods and stop accepting new connections before the app shuts down.
Surely I can’t be the only person deploying a meteor app without mup…
Bump.
You’re not the only one, I kinda hate mup, so I run my own deployments using nginx and meteor build. I’m pretty sure Meteor methods are cleaned up gracefully unless you hard kill the node process. Same goes for database writes, at least on MongoDB. Nginx has a graceful shutdown protocol as well, shutting down connections that first don’t have clients and then waits at least some time before killing active connections.
Depending on how fast your server(s) is/are this is a pretty marginal concern, especially if you’re using a job handler/watchdog like Upstart. Process termination protocols clean things up relatively nicely/quickly, and unless you have some long running methods, your users should have a decent experience. The only potential problem there is if you do have a lengthy method execution, restarting the app will cause the client to automatically re-run the method on re-connection (in most cases), which depending on what the method is doing can cause you to commit duplicate DB operations and stuff. There are some ways to mitigate that potential problem though, like making your methods idempotent, having a responsible data model, etc. I believe you can read up on it in the guide.
My best advice would be to test those edge cases and not worry so much about anything else 
Thanks for the reply. I’m just worried because it doesn’t shutdown normally; it shuts down with a timeout code which leads me to believe it could potentially cut off while it’s doing something.
Yeah, I hear you. Generally speaking though, unless you are explicitly aware of edge cases being tripped in your app and/or duplicate data being written, I wouldn’t worry too much.
Personally, one thing I’d love to do is enhance my Upstart jobs to gracefully cut over from one release to another, unless I set a $FORCE variable or something in case of big new feature releases or urgent hotfixes. So that users connected to one instance of the app will remain on the previous release until they timeout or disconnect, and new users will be automatically connected to the new release.
MDG has released a new npm package, which should help:
Linking that in with the Meteor.onConnection#onClose function should allow you to do any clean-up.
I’ve only just found this package, so haven’t had the chance to test it yet.
Huh, surprising this isn’t default in core Meteor packages.
There’s a blog post here:
Assuming the feedback is positive, we will likely make this be the default behavior of a future release of Meteor.
Is there a better answer in 2024?