Manual verification steps required after failed nginx master binary replacement

Goal: Verify that a replacement nginx master binary can be safely activated and, if the new binary fails, roll back to the previous binary without losing active connections.

Constraints: The upgrade relies on sending USR2 to rename the master process and create a .oldbin PID file; package manager may overwrite the binary, the .oldbin convention may not be guaranteed, and nginx -t only checks configuration syntax, not binary ABI or module compatibility.

Questions:

1. What verification steps must be performed on a staging host to confirm the new binary can bind ports and load required modules before signaling the master?
2. How can rollback be executed reliably when the old master may have already exited or the .oldbin PID file references an incorrect process?