Updating VMODs with zero downtime

[Carlos Abalde]

On 30 Jul 2014, at 09:58, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> So one murky bit here is if your OS's dlopen(3) implementation discovers
> that the file has changed.  It sounds like it doesn't, and just reuses
> the old already loaded copy :-(
> 
> The surefire way to fix that is to append a version number to the
> vmod filename, but it's kind of ugly...

Hi,

I've been checking the sources of Varnish and doing some more testing, and, as you suggest, this definitely seems related to dlopen(3) / dlclose(3) and how they are used when reloading Varnish. 

When reloading Varnish, the current VCL is deactivated and the new one loaded and activated. Assuming both the old and the new VCL import the VMOD to be updated with zero downtime, reference counting for that VMOD never drops to 0 (in fact the number of references is going to be 2 after reloading the service).This implies that dlclose(3) will never be called for the VMOD (VRT_Vmod_Fini), and further calls to dlopen(3) will always return a handle to the original VMOD, even if the VMOD / library changed on disk. This sounds consistent with the explanation in the man page of dlopen(3):

       If  the  same library is loaded again with dlopen(), the same file handle is returned.  The dl library maintains reference counts for library handles, so a dynamic library is not deallocated until dlclose(3) has been called on it as many times as dlopen() has succeeded on it.


I've also checked that if the original VCL is replaced by a new intermediate VCL not loading the VMOD, then the original VCL is discarded using the CLI (which generates a call to dlclose(3)), and finally the intermediate VCL is again replaced with the original one, then the VMOD is correctly reloaded from disk.


I considered copying the new VMOD to a different file and using something like "import example from "/usr/lib64/varnish/vmods/libvmod_example_new.so";", but it does not work. When reloading Varnish it checks that a VMOD with that name is already loaded and does not execute the dlopen(3) (VRT_Vmod_Init). 


In summary, I'm afraid that your suggestion of versioning module names that may require upgrades with zero downtime is the only option here... :/


Thanks!

—
Carlos Abalde.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20140731/93a981d0/attachment.pgp>