Which signal handling strategy ensures zero-downtime restarts in a Plack-based Perl application?

The Recommended Signal Strategy

To achieve zero-downtime restarts in a Plack-based application using a pre-forking server like Starman, the recommended strategy is sending the SIGUSR1 signal to the master process. Unlike SIGHUP, which in many Unix environments is used for general configuration reloads or terminal hang-ups, SIGUSR1 is specifically implemented by Starman to trigger a graceful restart cycle.

How Graceful Migration Works

When the master process receives SIGUSR1, it does not immediately kill existing workers. Instead, it follows this sequence:

1. The master process spawns a new set of worker processes running the updated code.
2. New incoming TCP connections are routed to the new workers.
3. Existing workers continue to process their current active requests.
4. Once an old worker completes its final in-flight request, it exits voluntarily.

Resetting Global State and Memory

The primary mechanism for ensuring that global state is fully reset is the pre-forking model itself. Because the master process spawns entirely new OS-level worker processes, the memory space for the new workers is clean. Any global variables, module-level state, or cached data residing in the memory of the old workers are destroyed when those processes terminate.

Note on State Persistence: This strategy only resets in-memory state. If your application relies on external state (e.g., Redis, Memcached, or a database), those must be managed via versioned keys or migration scripts, as they persist across process restarts.

Verification and Implementation

To trigger a graceful restart in a production environment, identify the master PID and send the signal:

kill -USR1 

To verify the transition is occurring without downtime:

• Run ps aux | grep starman during the restart to observe both old and new worker PIDs coexisting momentarily.
• Monitor your access logs for a continuous stream of 200 OK responses without a spike in 5xx errors during the signal window.

Assumptions and Constraints

This recommendation assumes you are using Starman as your PSGI server. Other servers, such as HTTP::Server::PSGI, may have different signal mappings or require external process managers (like systemd) to handle the restart logic. Additionally, if your application code defines its own SIGUSR1 handler, it may intercept the signal and prevent the server from restarting.

Missing Diagnostic Detail: Are you utilizing a process manager (e.g., systemd, Supervisor) or a container orchestrator (e.g., Kubernetes) to manage the master process? This determines whether the signal should be sent manually or via a management API.