Plack::Middleware::Restart: Zero‑downtime migration on Starman vs. Cherokee

Question

Plack::Middleware::Restart: Zero‑downtime migration on Starman vs. Cherokee
The goal is to upgrade a small PSGI web application without dropping any active connections. Plack::Middleware::Restart achieves this by spawning a child process, keeping the listening socket open, and swapping parent and child. However, the middleware’s behavior depends on the underlying PSGI server’s graceful‑shutdown support.
Starman natively supports graceful shutdown, allowing the middleware to maintain connections during restart. Cherokee, on the other hand, requires explicit configuration to keep sockets open; otherwise, active connections are terminated immediately, defeating the zero‑downtime objective.
Additionally, the middleware relies on Perl 5.10+ for lexical signal handling and Plack 1.4+ for socket transfer APIs. Older servers or versions may lack the necessary hooks, leading to unpredictable behavior.
Unresolved decisions and questions:

Will the current PSGI server (Starman or Cherokee) correctly preserve listening sockets during a Plack::Middleware::Restart trigger?
What configuration changes, if any, are required on Cherokee to emulate Starman’s graceful shutdown behavior?
How can in‑memory state be reliably preserved across the restart when using this middleware?

Siddharth · Answer

Answer the core question first
Starman natively supports graceful shutdown, so Plack::Middleware::Restart swaps the parent and child while keeping the listening socket open. Cherokee, by default, closes sockets on a hard restart; you must enable graceful‑shutdown in its config and use a reload command.
What changes are needed on Cherokee?
In /etc/cherokee/cherokee.conf (or via the web‑admin GUI) set GracefulShutdown On for the listener you wish to preserve. Then issue cherokee-admin --reload (or cherokee-admin --restart --graceful) instead of killing the process. This keeps the socket bound while the old worker exits.
Preserving in‑memory state
The middleware only swaps processes; it does not serialise your application’s globals. If your app relies on in‑memory data you have three practical options:

Forked memory – start the child with fork so it inherits the parent’s memory (works if the state is immutable or rebuilt on startup).
External store – move state to Redis, Memcached, or a database so the child can read fresh data on start‑up.
Signal‑based reload – have the parent catch SIGUSR1 and re‑initialise the state before forking.

Verification checklist

Run plackup --middleware Plack::Middleware::Restart app.psgi and watch the parent exit only after the child signals readiness.
Use lsof -i :port to confirm the socket remains bound during the swap.
For Cherokee, enable GracefulShutdown and run cherokee-admin --reload. Verify the socket stays open with netstat -an | grep LISTEN.
Test in‑memory state by setting a global variable before the restart and printing it after; if it persists, the memory was inherited.

Missing diagnostic detail
Which version of Cherokee are you running? Graceful shutdown support was added in 1.1.0; older releases will ignore the GracefulShutdown flag.

Plack::Middleware::Restart: Zero‑downtime migration on Starman vs. Cherokee

Plack::Middleware::Restart: Zero‑downtime migration on Starman vs. Cherokee

1 answer

Answer the core question first

What changes are needed on Cherokee?

Preserving in‑memory state

Verification checklist

Missing diagnostic detail

Your perspective belongs here.

0 question comments