On 30 Jul 2014, at 09:58, Poul-Henning Kamp <[email protected]> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
