Upgrading to 6.6 can't reload

[Dridi Boukelmoune]

>> 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.

This is very strange, I would probably need to somehow peek at the
working directory to figure out what's happening. The only way to see
no -T in shared memory is to explicitly ask for it with `-T none`,
which clearly you didn't do.

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

This on the other hand sounds like basic unix permissions coming
short, as one would expect.

> 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?

The varnishreload script is meant to focus on the system service
integration use case: you have a local Varnish instance that can also
be operated locally. So we shouldn't need to add options to specify -T
or -S, we should find them on the running instance.

You could use -T none if you have an alternative mode of operations.
For example varnishd -d puts you in debug mode and stdin/stdout is
used for the CLI. The alternative would be the -M option that lets
varnishd "reverse" connect to its operator, but then you would leave
the varnishreload use case.

Not sure about focal users, but I will try to spin up a VM and see if
I can reproduce it.

> 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.
>
> https://github.com/varnishcache/varnish-cache/blob/6.0/bin/varnishadm/varnishadm.c

Correct, the default behavior is to inspect the running Varnish
instance to find them.

>> 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 varnishlog.

That seems to indicate that Varnish may have been started on a
different hostname and what you are "connecting" to is the remnant of
a dead instance.

What is the output of `ls /var/lib/varnish` ?

> 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 would recommend sticking to the 6.0 LTS series, unless you
absolutely need a feature released after 6.0 that hasn't been
back-ported to the stable branch.

https://packagecloud.io/varnishcache/varnish60lts/install

If you don't use an LTS series, I recommend always sticking to the
latest release. The 6.2 series is EOL and no longer maintained, which
may include security vulnerabilities such as VSV7.

https://varnish-cache.org/security/VSV00007.html

Dridi