清漆缓存日志不起作用

Question

varnishlog is returning:

_.vsm: No such file or directory

Has anyone else seen this before?

Answer 1

It looks like varnishlog is not pointing to the correct directory, or has not access to it.

Please check the command line options of varnishd . If the deamon run with -n <instancename> argument, you have to add it to varnishlog as well.

The second thing, is to see the permissions of varnish directory. In order to see the current directory used, you must log into root and run the command below :

$ lsof -p <PID of varnishd> | grep vsm

Once revealed, you just had to be sure the full path has read permission for your user.

Answer 2

In Varnish 4.1 the root cause can be due to incorrect rights for reading _.vsm file. For example:

# service varnishncsa start
 * Starting HTTP accelerator log deamon                                                                                                                                                               [fail] 
Can't open log - retrying for 5 seconds
Can't open VSM file (Cannot open /var/lib/varnish/dev-me/_.vsm: Permission denied

Varnishncsa works from varnishlog user. But /var/lib/varnish/dev-me/_.vsm can be readable from varnish group or root user only:

# ls -l /var/lib/varnish/dev-me/_.vsm
-rw-r----- 1 root varnish 84934656 Apr 15 05:58 /var/lib/varnish/dev-me/_.vsm

So you can fix this problem in the following way:

# usermod -a -G varnish varnishlog
# id varnishlog
uid=110(varnishlog) gid=116(varnishlog) groups=116(varnishlog),115(varnish)

And now you can start varnishncsa.

Answer 3

In our case the hostname of the server was changed.

If you do not specify an instance name, varnish uses the hostname. It was looking for a directory holding the shared memory logging configuration with the new hostname, but the instance was still running from the directory with the old hostname.

Restarting varnish solved the problem.

Answer 4

I just had the same error message while trying to issue varnishadm commands. Turned out that I renamed my machine without stopping varnish. There was some directory in /var/varnish/ corresponding to the machine name that varnish needed access to. "sudo service varnish restart" fixed this for me.