>> 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 _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
