Upgrading to 6.6 can't reload

Richard Chivers r.chivers at zengenti.com
Wed Jun 23 06:21:27 UTC 2021

Hey, thanks for coming back to me, I have done some more work, but haven't
got any further at this stage.

On Mon, Jun 21, 2021 at 9:01 AM Dridi Boukelmoune <dridi at varni.sh> wrote:

> On Mon, Jun 21, 2021 at 6:45 AM Richard Chivers <r.chivers at zengenti.com>
> wrote:
> >
> > Hi, thanks for coming back. No, the hostname didn't change. Here is the
> rest of the file:
> >
> > [Unit]
> <snip>
> >                                 -S /etc/varnish/secret \
> Can you try removing the -S option from varnishd?
> Since you only listen to the CLI on localhost, there's likely no
> remote access, so leaving the secret out will make varnishd generate a
> random one. Basically, if you want to use varnishadm you need local
> root privileges, same as your current setup.

I tried this and it makes no difference, I think the fundamental issue is
that calling varnishadm without args seems (regardless the args I pass to
varnishd) to end in the message "No -T in shared memory"  if run from root.

If I run from another user, I do get the message "could not get hold of
varnishd, is it running?"

I guess I could update the reload script to pass the -T and -S args, but
this seems wrong, just concerned there is a general issue on focal, Is
anyone else running 6.6 on focal?

Looking at the source code in 6 and 6.6 I can't see anywhere that the -T
would default from and yet on 6 under bionic varnishadm as a root user just
works without any -T or -S flags.


> <snip>
> >> > In bionic when we run a varnishadm, we don't need to pass the -T or
> -S args, it just reads the secret file ( I am assuming) and connects.
> >> >
> >> > In focal this is not the case, I need to pass the args. e.g.
> varnishadm -T localhost:6082 -S /etc/varnish/secret
> The main entry point is the -n option, and then options (or lack
> thereof) like -T and -S can be found from the working directory.
> >> > Because of this calling /usr/sbin/varnishreload fails because it
> calls varnishadm -n '' -- vcl.list and gets the response "No -T in shared
> memory"
> >> >
> >> > So my question is where does this default from, is there an ENV
> variable to set, or am I just missing something?
> >>
> >> Did your system's hostname change between the moment when varnish was
> >> started and when you attempted a reload?
> >>
> >> Can you share the rest of your service file? (maybe redact sensitive
> >> parts if any)
> I didn't have time to give more details, but the default value for -n
> is the system's hostname, that's why I asked initially about the
> hostname changing.
> >> > Another strange issue is that varnishlog is not returning anything,
> it simply hangs and doen't show anything or an error for that matter.
> Are you running varnishlog with enough privileges? (most likely
> belonging at least to the varnish group.)
> If you omit the -d option, varnishlog will print transactions as they
> complete, so if by any chance you are inspecting a test system with no
> traffic that's not surprising.
> A surefire way to see whether varnishlog connects to a running varnish
> instance is to try:
>     varnishlog -d -g raw

I am running as root. If I execute this it connects but I get no output, I
know it is connected because when I restart the varnish process I get the
message, "Log abandoned (vsm)" which you always see when a new
varbnishd process starts. I am definitely hitting the varnish server, as I
am executing curl requests to localhost:80, but there is no output from

I am about to spin up some more boxes, so will check to see wheter this is
just specific to this box or not, I did initially install 6.2 on this
server and varnishlog was working as expected with that.

> >> > I Installed by adding the repo: deb
> https://packagecloud.io/varnishcache/varnish66/ubuntu/ focal main
> >> >
> >> > Any ideas or help appreciated.
> >> >
> >> > I have gone back through change logs, but can't spot anything.
> >> >
> >> > Thanks
> >> >
> >> > Richard
> Please keep the mailing list CC'd.
> Dridi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20210623/b46ef090/attachment-0001.html>

More information about the varnish-misc mailing list