A Quick Server Reloader Designed for Go

Yukiko Añonuevo
ClearGraph
Published in
2 min readJan 22, 2015

Original post written by Jin Pan on January 22, 2015.

At Argo, we use Go for many of our production services. Spoiled by Go’s fast compiler, I wanted to avoid the rote cycle of go install <alt-tab> <ctrl-c> <ctrl-p> <alt-tab>.

We investigated a few reloaders for Go, such as Codegangsta’s gin and Scalingo’s graceful restart. Codegangsta’s gin continuously and recursively polls the source directory of the server, looks for any changes in Go source files and forces a server restart. Scalingo’s graceful reloader requires some changes to the underlying source code so it can magically reload the server without causing any in-flight requests to fail.

None of the reloaders out there seemed to do exactly what we wanted — the server should only reload when I explicitly issue a compile — not whenever I save a source file in the middle of a larger change. I generally like magic, but Scalingo’s reloader seems too invasive and magical for where we are — I want this to be an opt-in reloader so that the reloader does not affect production services or require other Argo devs to adopt my workflow.

On to the design

In principle, such a reloader should be incredibly simple:

binary_changed:
kill old server
start new server
when server binary is recreated, call `binary_changed`

In practice, creating such a reloader is also fairly simple, and I implemented a cross-platform reloader one afternoon in Python. We’ll discuss the specific implementation of the reloader now and conclude with the open source code at the end.

We create a helper function to create a new process and return its id. This function forks to create a new child process, runs the provided executable in the parent process, and the child fork returns the process id of the parent. We store this process id to kill the executable so we can create a new instance of it.

To watch the binary file, we use watchdog, which a cross platform wrapper around Linux’sinotify, OSX’s fswatch, and Windows’ FileSystemWatcher. These system calls easily allow us to register callback functions upon specific file system events, such as file creation, deletion, modification, movement, etc. This avoids the wasteful polling employed by some of the other reloaders while offering low and predictable restart latency, which in practice means a consistently near-instantaneous reloading process.

For many of our executable services, we have them espeak or say a cute startup message, which is a reassuring notification that the reloader has succeeded.

We’ve open sourced our reload script for executables under the MIT license on Github.

Originally published at argo.io on January 22, 2015.

--

--

Yukiko Añonuevo
ClearGraph

UX Designer, Front-end Developer. Doer of many things.