<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I don't believe this a log rotate problem as I gave logrotate scheduled to run at midnight. I think this might be related to how amazon ec2 instances sometimes change their hostnames - after varnish starts - and if I recall the various varnish binaries make use of the hostname to find the cache (file or memory.)</div>
<div><br></div><div>Might be this but then why does varnishd and varnishd work okay and only logrotate does not?</div><div><br>On Mar 14, 2014, at 5:02 PM, Stephen Wood <<a href="mailto:smwood4@gmail.com">smwood4@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div>My first thought is that logrotate is running and varishncsa is not properly catching a SIGHUP after a rotate. Therefore the logfile gets rotated but varnishncsa continues writing to the old fd.</div>
<div>
<br></div><div>If you run <font face="courier new, monospace">varnishncsa</font> by itself on the command line during these periods, do you get output? If so then it's probably not a problem with shared memory. </div>
<div><br></div><div><div>If you want to test this, you can simply change the varnishncsa logrotate behavior to use copytruncate and not bother sending a HUP, which will truncate the log without rotating it.</div></div><div>
<br></div><div>For reference here's what my logrotate file looks like:</div><div><br></div><div><div><font face="courier new, monospace">/var/log/varnish/varnish.log /var/log/varnish/varnishncsa.log {</font></div><div>
<font face="courier new, monospace"> size 1G</font></div><div><font face="courier new, monospace"> rotate 7</font></div><div><font face="courier new, monospace"> missingok</font></div><div><font face="courier new, monospace"> compress</font></div>
<div><font face="courier new, monospace"> delaycompress</font></div><div><font face="courier new, monospace"> postrotate</font></div><div><font face="courier new, monospace"> for service in varnishlog varnishncsa; do</font></div>
<div><font face="courier new, monospace"> if /usr/bin/pgrep -P 1 $service >/dev/null; then</font></div><div><font face="courier new, monospace"> service $service reload > /dev/null</font></div><div><font face="courier new, monospace"> fi</font></div>
<div><font face="courier new, monospace"> done</font></div><div><font face="courier new, monospace"> endscript</font></div><div><font face="courier new, monospace">}</font></div></div><div><font face="courier new, monospace"><br>
</font></div>If you want to try copytruncate:<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace"><div>/var/log/varnish/varnish.log /var/log/varnish/varnishncsa.log {</div><div>
size 1G</div><div> rotate 7</div><div> missingok</div><div> compress</div><div> delaycompress</div><div> copytruncate</div><div>}</div><div><br></div></font>Note that you'll get a message in your log file that states it was truncated. It may mess up your log parsing software.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 4:33 AM, Raymond Jennings <span dir="ltr"><<a href="mailto:raymond.jennings@nytimes.com" target="_blank">raymond.jennings@nytimes.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have what might be a related problem. I can only get varnishlog to<br>
write to a file after I stop it and restart it. I am running on ec2.<br>
I tried various tricks to wait so many seconds after varnished starts<br>
then start varnishlog. Varnishncsa runs perfectly fine right out of<br>
the gate. I have had this problem for about two years now.<br>
Varnishlog is clearly running and "service varnishlog stop"<br>
successfully stops it. "service varnishlog start" and things are<br>
good.<br>
<div class=""><br>
> On Mar 13, 2014, at 6:27 AM, Thomas Lecomte <<a href="mailto:thomas.lecomte@virtual-expo.com">thomas.lecomte@virtual-expo.com</a>> wrote:<br>
><br>
>> On Thu, Mar 13, 2014 at 10:25:52AM +0100, Cédric Jeanneret wrote:<br>
>><br>
</div>>> Hmm, _.vsm is shown when we perform a simple "ls" in the directory...<br>
<div class="">>> Else, I would get some errors from either varnishncsa or varnishlog when<br>
</div>>> I start them (I tried that this morning, just to see what would happen)...<br>
<div class="HOEnZb"><div class="h5">><br>
> Maybe you could compare the inodes using ls -i on the visible _.vsm<br>
> against the one shown by lsof on the varnish process.<br>
><br>
> --<br>
> Thomas Lecomte / <a href="tel:%2B33%204%2086%2013%2048%2065" value="+33486134865">+33 4 86 13 48 65</a><br>
> Sysadmin / Virtual Expo / Marseille<br>
><br>
> _______________________________________________<br>
> varnish-misc mailing list<br>
> <a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
> <a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
<br>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Stephen Wood<div><a href="http://www.heystephenwood.com" target="_blank">www.heystephenwood.com</a></div></div>
</div>
</div></blockquote></body></html>