2018-10-11
5 min read
Dingle Dangle! by Grant C. (CC-BY 2.0)
The idea behind graceful upgrades is to swap out the configuration and code of a process while it is running, without anyone noticing it. If this sounds error-prone, dangerous, undesirable and in general a bad idea – I’m with you. However, sometimes you really need them. Usually this happens in an environment where there is no load balancing layer. We have these at Cloudflare, which led to us investigating and implementing various solutions to this problem.
Coincidentally, implementing graceful upgrades involves some fun low-level systems programming, which is probably why there are already a bajillion options out there. Read on to learn what trade-offs there are, and why you should really use the Go library we are about to open source. For the impatient, the code is on GitHub and you can read the documentation on godoc.
The basics
So what does it mean for a process to perform a graceful upgrade? Let’s use a web server as an example: we want to be able to fire HTTP requests at it, and never see an error because a graceful upgrade is happening.
We know that HTTP uses TCP under the hood, and that we interface with TCP using the BSD socket API. We have told the OS that we’d like to receive connections on port 80, and the OS has given us a listening socket, on which we call Accept() to wait for new clients.
A new client will be refused if the OS doesn’t know of a listening socket for port 80, or nothing is calling Accept() on it. The trick of a graceful upgrade is to make sure that neither of these two things occur while we somehow restart our service. Let’s look at the all the ways we could achieve this, from simple to complex.
Just Exec()
Ok, how hard can it be. Let’s just Exec() the new binary (without doing a fork first). This does exactly what we want, by replacing the currently running code with the new code from disk.
// The following is pseudo-Go.
func main() {
var ln net.Listener
if isUpgrade {
ln = net.FileListener(os.NewFile(uintptr(fdNumber), "listener"))
} else {
ln = net.Listen(network, address)
}
go handleRequests(ln)
<-waitForUpgradeRequest
syscall.Exec(os.Argv[0], os.Argv[1:], os.Environ())
}Unfortunately this has a fatal flaw since we can’t “undo” the exec. Imagine a configuration file with too much white space in it or an extra semicolon. The new process would try to read that file, get an error and exit.
Even if the exec call works, this solution assumes that initialisation of the new process is practically instantaneous. We can get into a situation where the kernel refuses new connections because the listen queue is overflowing.
New connections may be dropped if Accept() is not called regularly enough
Specifically, the new binary is going to spend some time after Exec() to initialise, which delays calls to Accept(). This means the backlog of new connections grows until some are dropped. Plain exec is out of the game.
Listen() all the things
Since just using exec is out of the question, we can try the next best thing. Lets fork and exec a new process which then goes through its usual start up routine. At some point it will create a few sockets by listening on some addresses, except that won’t work out-of-the-box due to errno 48, otherwise known as Address Already In Use. The kernel is preventing us from listening on the address and port combination used by the old process.
Of course, there is a flag to fix that: SO_REUSEPORT. This tells the kernel to ignore the fact that there is already a listening socket for a given address and port, and just allocate a new one.
func main() {
ln := net.ListenWithReusePort(network, address)
go handleRequests(ln)
<-waitForUpgradeRequest
cmd := exec.Command(os.Argv[0], os.Argv[1:])
cmd.Start()
<-waitForNewProcess
}Now both processes have working listening sockets and the upgrade works. Right?
SO_REUSEPORT is a little bit peculiar in what it does inside the kernel. As systems programmers, we tend to think of a socket as the file descriptor that is returned by the socket call. The kernel however makes a distinction between the data structure of a socket, and one or more file descriptors pointing at it. It creates a separate socket structure if you bind using SO_REUSEPORT, not just another file descriptor. The old and the new process are thus referring to two separate sockets, which happen to share the same address. This leads to an unavoidable race condition: new-but-not-yet-accepted connections on the socket used by the old process will be orphaned and terminated by the kernel. GitHub wrote an excellent blog post about this problem.
The engineers at GitHub solved the problems with SO_REUSEPORT by using an obscure feature of the sendmsg syscall called ancilliary data. It turns out that ancillary data can include file descriptors. Using this API made sense for GitHub, since it allowed them to integrate elegantly with HAProxy. Since we have the luxury of changing the program we can use simpler alternatives.
NGINX is the tried and trusted workhorse of the Internet, and happens to support graceful upgrades. As a bonus we also use it at Cloudflare, so we were confident in its implementation.
It is written in a process-per-core model, which means that instead of spawning a bunch of threads NGINX runs a process per logical CPU core. Additionally, there is a primary process which orchestrates graceful upgrades.
The primary is responsible for creating all listen sockets used by NGINX and sharing them with the workers. This is fairly straightforward: first, the FD_CLOEXEC bit is cleared on all listen sockets. This means that they are not closed when the exec() syscall is made. The primary then does the customary fork() / exec() dance to spawn the workers, passing the file descriptor numbers as an environment variable.
Graceful upgrades make use of the same mechanism. We can spawn a new primary process (PID 1176) by following the NGINX documentation. This inherits the existing listeners from the old primary process (PID 1017) just like workers do. The new primary then spawns its own workers:
CGroup: /system.slice/nginx.service
├─1017 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─1019 nginx: worker process
├─1021 nginx: worker process
├─1024 nginx: worker process
├─1026 nginx: worker process
├─1027 nginx: worker process
├─1028 nginx: worker process
├─1029 nginx: worker process
├─1030 nginx: worker process
├─1176 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─1187 nginx: worker process
├─1188 nginx: worker process
├─1190 nginx: worker process
├─1191 nginx: worker process
├─1192 nginx: worker process
├─1193 nginx: worker process
├─1194 nginx: worker process
└─1195 nginx: worker processAt this point there are two completely independent NGINX processes running. PID 1176 might be a new version of NGINX, or could use an updated config file. When a new connection arrives for port 80, one of the 16 worker processes is chosen by the kernel.
After executing the remaining steps, we end up with a fully replaced NGINX:
CGroup: /system.slice/nginx.service
├─1176 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─1187 nginx: worker process
├─1188 nginx: worker process
├─1190 nginx: worker process
├─1191 nginx: worker process
├─1192 nginx: worker process
├─1193 nginx: worker process
├─1194 nginx: worker process
└─1195 nginx: worker processNow, when a request arrives the kernel chooses between one of the eight remaining processes.
This process is rather fickle, so NGINX has a safeguard in place. Try requesting a second upgrade while the first hasn’t finished, and you’ll find the following message in the error log:
[crit] 1176#1176: the changing binary signal is ignored: you should shutdown or terminate before either old or new binary's processThis is very sensible, there is no good reason why there should be more than two processes at any given point in time. In the best case, we also want this behaviour from our Go solution.
Graceful upgrade wishlist
The way NGINX has implemented graceful upgrades is very nice. There is a clear life cycle which determines valid actions at any point in time:
It also solves the problems we’ve identified with the other approaches. Really, we’d like NGINX-style graceful upgrades as a Go library.
No old code keeps running after a successful upgrade
The new process can crash during initialisation, without bad effects
Only a single upgrade is active at any point in time
Of course, the Go community has produced some fine libraries just for this occasion. We looked at
github.com/alext/tablecloth (hat tip for the great name)
just to name a few. Each of them is different in its implementation and trade-offs, but none of them ticked all of our boxes. The most common problem is that they are designed to gracefully upgrade an http server. This makes their API much nicer, but removes flexibility that we need to support other socket based protocols. So really, there was absolutely no choice but to write our own library, called tableflip. Having fun was not part of the equation.
tableflip
tableflip is a Go library for NGINX-style graceful upgrades. Here is what using it looks like:
upg, _ := tableflip.New(tableflip.Options{})
defer upg.Stop()
// Do an upgrade on SIGHUP
go func() {
sig := make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGHUP)
for range sig {
_ = upg.Upgrade()
}
}()
// Start a HTTP server
ln, _ := upg.Fds.Listen("tcp", "localhost:8080")
server := http.Server{}
go server.Serve(ln)
// Tell the parent we are ready
_ = upg.Ready()
// Wait to be replaced with a new process
<-upg.Exit()
// Wait for connections to drain.
server.Shutdown(context.TODO())Calling Upgrader.Upgrade spawns a new process with the necessary net.Listeners, and waits for the new process to signal that it has finished initialisation, to die or to time out. Calling it when an upgrade is ongoing returns an error.
Upgrader.Fds.Listen is inspired by facebookgo/grace and allows inheriting net.Listener easily. Behind the scenes, Fds makes sure that unused inherited sockets are cleaned up. This includes UNIX sockets, which are tricky due to UnlinkOnClose. You can also pass straight up *os.File to the new process if you desire.
Finally, Upgrader.Ready cleans up unused fds and signals the parent process that initialisation is done. The parent can then exit, which completes the graceful upgrade cycle.