-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for graceful reload #69
Conversation
Well, unless the main process gets the last pid before the OS cycles back to the beginning. In which case, the main pid will be much larger. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nikmolnar nicely done! Appears to work as expected.
Please add usage instructions to the README.
|
||
server.TLSConfig.GetCertificate = e.AutoTLSManager.GetCertificate | ||
server.TLSConfig.NextProtos = append(server.TLSConfig.NextProtos, acme.ALPNProto) | ||
if !e.DisableHTTP2 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no server.StartAutoTLS
to replace e.StartAutoTLS
, so I stole the implementation of e.StartAutoTLS
and just in-lined it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this is part of that implementation.
This PR adds support for gracefully reloading the server configuration (without dropping any in-progress connections or refusing any new ones) upon receiving a
HUP
signal.(the main pid will always be the smaller one)
The strategy is to fork a child process on start, rather than handling requests in the main process. The main process binds a listener to the desired port and passes that listener to the child process so that it can accept new requests.
When a reload is requested, the parent process creates a replacement child process, passing it the same listener. It send the original child process a signal to gracefully shutdown, after fulfilling pending connections. It also implements a timer, ensuring the process is stopped eventually in the event of a hang. The parent is now ready for another reload signal.
As far as testing, I've continually reloaded the server, while requesting tiles via the mbtileserver service map page using a throttled connection, and have not seen any tiles drop.