2

Let's say that I'm running Nginx as my webserver. I know that Nginx handles the -s reload command which will reload the configuration when it's changed, but waits around for current requests to finish before it cycles the worker processes to use the new config, so hooray, no downtime!

But what about changing actual files?

For instance, let's say that I've got an index.html and I've realized there's a typo in my page. Let's also say that it's a highly active page (like StackOverflow, for example) and I want to fix my typo.

If I just go edit the file with a text editor, or update it with rsync or scp or something, is it possible for a request to get fouled up?

For instance, say I'm running on a multicore machine and the request comes in from the client through Nginx to load up index.html, and at the very same time data starts coming in from me to update index.html.

Is there any kind of circumstance where the client would only get a partially finished file? Or a file that contains old data that was on the disk in the location of that new file?

Or are there some sorts of guarantee around that not happening. I understand the probability of such events actually happening are pretty slim, but what's the simplest method that guarantees both uptime and accessing only the correct files?

  • Just a thought, "a highly active page (like StackOverflow, for example)" would almost always actually be using some sort of cache download network ("CDN"), such as AWS CloudFront, CloudFlare, MaxCDN, Azure CDN, etc. Hence the 'origin' webserver (your Nginx instance), would only see (occasional) requests from these services to update their cache. – Tersosauros Oct 17 '16 at 11:32
  • @Tersosauros naturally :) I'm curious about what would happen in a world without a CDN, or even a load balancer – Wayne Werner Oct 17 '16 at 16:24
3

If I just go edit the file with a text editor, or update it with rsync or scp or something, is it possible for a request to get fouled up?

For text editors (at least all the common ones), rsync, or scp, it is not possible. Any halfway competent programmer would guard against that.

For "or something", it depends on whether or not that "something" was written by a halfway competent programmer.

Normally, programs that may be used to update live files, are written in such a way to make those updates atomically. On almost all filesystems on almost all Unices in use today, renameing a file is atomic, so text editors will first write to a temporary "swap" file, and then atomically rename the swap file to the actual file name.

However, in the latter case, all programs that have already opened the file, will still have the (now deleted) old file open. They will have to close and re-open the file. But a web server will probably never keep a file open after having sent it. The only file it will keep open is the log file, for continuous writing. (That's why you need to restart your webserver when you use some kind of log rotation, because otherwise, even after you rotated away the old logfile and created a new one, the webserver's open file descriptor is still the one of the old file. It's also why long-running servers with logging functionality use usually trap the HUP signal and interpret it as a request to close and re-open the log file, precisely so that you don't need to restart them (and risk a brief period of suspension of service).)

  • 1
    So scp, et. al (and presumably git and mercurial) are actually creating files at a new inode and once the file has been fully created only then does it change the filename to point to the new inode? – Wayne Werner Oct 17 '16 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.