Summary

This PR adds a server-side Meteor.onShutdown(fn) lifecycle hook, intended as the shutdown counterpart to Meteor.startup(fn).

Registered hooks are called on SIGTERM and SIGINT before the process exits, allowing applications to flush logs, drain queues, release locks, close sockets, or finish pending async cleanup before the supervisor escalates to SIGKILL.

Why

Meteor exposes Meteor.startup(fn) for the boot side of the lifecycle, but there's no symmetric API for shutdown. Today, applications that need to clean up on termination attach raw process.on('SIGTERM', …) handlers themselves, and the details that matter — per-hook timeout, error containment, ordering, single-point-of-exit — have to be reimplemented in each app.

This PR codifies the missing half of the lifecycle so applications can rely on a consistent, framework-level shutdown hook.

Forum context: https://forums.meteor.com/t/is-there-something-like-meteor-shutdown/64602

Use cases

Patterns this enables:

• Drain in-flight DB writes / transactions before the driver connection closes.
• Job-queue drain — finish persisting pending jobs before stopping the consumer, so redeploys don't lose work.
• Telemetry / logger flush — pino, winston, Sentry, OpenTelemetry exporters all have async flush methods that need to complete before exit.
• Distributed lock release — Redis / etcd locks held by the process released proactively rather than waiting for TTL.

What changed

• tools/static-assets/server/boot.js — shutdownHooks: [] bucket, callShutdownHooks(signal) runner, SIGTERM / SIGINT listeners.
• packages/meteor/startup_server.js — public Meteor.onShutdown(fn) API.
• docs/source/api/core.md — apibox entry + prose, placed right after Meteor.startup.

Usage

import { Meteor } from 'meteor/meteor';

Meteor.onShutdown(async (signal) => {
  console.log(`Shutting down on ${signal}, flushing pending writes…`);
  await jobQueue.flush();
  await mongoClient.close();
});

Hooks receive the triggering signal name ('SIGTERM' or 'SIGINT') as their argument.

Design choices

Exit codes follow POSIX: SIGINT → 130, SIGTERM → 143.

Review feedback resolved

Following @italojs's review (the four open questions the draft was waiting on are now settled):

1. API name — renamed Meteor.shutdown → Meteor.onShutdown.
2. Hook ordering — LIFO (teardown symmetry).
3. METEOR_SHUTDOWN_TIMEOUT_MS — 0 = no cap, 1 ≈ immediate, invalid/negative → default 10000 with a warning (no more silent coercion).
4. Double Ctrl-C escape hatch — a second SIGTERM/SIGINT during shutdown now forces an immediate exit instead of being swallowed.
5. Style — const/let throughout the new code.

Signal coverage stays SIGINT/SIGTERM only; SIGHUP and Node's 'exit' remain out of scope for a follow-up.

Known limitations / out of scope

This PR does not refactor existing shutdown-related listeners such as packages/webapp/socket_file.js, and it does not integrate the dev-mode parent watchdog (startCheckForLiveParent, boot.js:180) with the new hook runner. In dev mode, hooks taking longer than ~3s can therefore be pre-empted by the watchdog process.exit(1); in production builds (no METEOR_PARENT_PID) the METEOR_SHUTDOWN_TIMEOUT_MS cap is the sole guard. Both can be handled in follow-up PRs.

Validation

Manual validation against a fresh meteor create --blaze app.