When I ask my friends “have you read my blog?” they usually answer “yes”, followed by “I should start a blog too.” True, it’s difficult to get started, but the good news is that getting started is actually the hardest part. If you start by thinking about what you want to say and jotting down an outline, the rest of the blog post (or documentation for a project) usually comes pretty easily. And I’m not the only one to think so — I just read a blog post by Stoyan Stefanov who essentially says the same thing, except he’s talking about writing technical books. If you’re having a hard time getting started, give it a read.
I’ve been working with Varnish a lot this month. Since installing Varnish itself is pretty simple, “working with Varnish” usually means changing the VCL to get Varnish to behave the way you want it to. And if you’re editing VCL, you probably want to know if it compiles or not before you check it in or deploy it. Fortunately, there’s a command for that:
sudo varnishd -C -f /path/to/your.vcl
This will print out the VCL compiled as C code if the VCL is valid. If the VCL is not valid, an error message will be printed instead. For example, running this against a VCL file with no backends defined prints this error:
Message from VCC-compiler: No backends or directors found in VCL program, at least one is necessary. Running VCC-compiler failed, exit 1
Despite what the error message says about the exit code, Varnish always exits 0 — even if there’s an error. This bug has been fixed, but the fix is not part of the latest stable 3.0.2 release.
Over the last week, I’ve encountered two incidents where an incorrect DNS entry was created and started causing problems. In one case, Varnish wouldn’t start because one of the backends resolved to multiple IPs. In the other, a Mongo node was pointing at the wrong IP. In both cases, the DNS entry was corrected and the changes propagated, but the problem hosts themselves were still seeing the stale entries.
I remembered that we were running nscd, so I restarted the service to flush the cache. Unfortunately, that didn’t help. A colleague informed me that
nscd‘s cache is actually persistent by default on CentOS 6. To flush it, you need to run
nscd -i hosts
-i stands for invalidate.
You can also check if
nscd‘s cache is persistent by running
and looking for
cache is persistent. Note that
nscd caches several other types of data (not just DNS entries), so if you’re looking for the DNS cache specifically, make sure to look under the
hosts cache section.