Ran into an issue lately where a failed deployment led to unicorn not starting, the old unicorn dying, and the 'upgrade' task returning success.
From looking at the default unicorn_init.rb, it seems to trigger the upgrade, wait 2 seconds, then check if the new master process is still there and kill the old one.
This does mean if there is a problem with the new process after 2 seconds, it will fail, and the old process will be gone so there's nothing to revert back to.
Seems to be a simple fix, the oldsig QUIT instruction doesn't seem to be needed anymore, unicorn will kill the old process once the new master is running successfully and revert back to the old master if the new master fails, so I've taken the olsig QUIT out and let the unicorn behaviour handle this itself.
I also added a check to see if the PID has changed after the upgrade to check if the upgrade was successful.
This gem isn't dependent on a specific unicorn gem or version from what I can see though so in case this behaviour isn't the same everywhere I could implement it as a different task like safe_upgrade rather than making a potentially breaking change to the upgrade task.
Hello all,
Ran into an issue lately where a failed deployment led to unicorn not starting, the old unicorn dying, and the 'upgrade' task returning success.
From looking at the default unicorn_init.rb, it seems to trigger the upgrade, wait 2 seconds, then check if the new master process is still there and kill the old one.
This does mean if there is a problem with the new process after 2 seconds, it will fail, and the old process will be gone so there's nothing to revert back to.
Seems to be a simple fix, the oldsig QUIT instruction doesn't seem to be needed anymore, unicorn will kill the old process once the new master is running successfully and revert back to the old master if the new master fails, so I've taken the olsig QUIT out and let the unicorn behaviour handle this itself.
I also added a check to see if the PID has changed after the upgrade to check if the upgrade was successful.
This gem isn't dependent on a specific unicorn gem or version from what I can see though so in case this behaviour isn't the same everywhere I could implement it as a different task like
safe_upgraderather than making a potentially breaking change to the upgrade task.113