From hrhosseini at hotmail.com  Sat Jul  4 14:13:44 2020
From: hrhosseini at hotmail.com (hamidreza hosseini)
Date: Sat, 4 Jul 2020 14:13:44 +0000
Subject: solution for Active/Passive Backend
Message-ID: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>

Hi,
I want to have 2 or 3 backends in the Varnish config file but just one of them workes as an active backend and whenever my active backend failed , the second backend become active and respond the requests. (In other hand, I dont want to have two backend for responding clients and just one of them works at the same time, and it check the health status of my active backend , whenever it is was unhealthy , varnish switch to the second or third backend.)
Best Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200704/925c1e43/attachment.html>

From guillaume at varnish-software.com  Sat Jul  4 15:11:36 2020
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Sat, 4 Jul 2020 08:11:36 -0700
Subject: solution for Active/Passive Backend
In-Reply-To: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
References: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
Message-ID: <CAJ6ZYQyANFJf+JFVUXFWO5yD1H+Fa+Nxe5d_dNrtuTpX3rgYjQ@mail.gmail.com>

Hi,

You want to use probes and the fallback director.

Relevant documentation:
to define a probe:
https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#probes
to attach it to backends:
https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#backend-definition
the fallback director:
https://varnish-cache.org/docs/6.4/reference/vmod_directors.html?highlight=fallback#directors-fallback

i also wrote these blog posts a long time ago, but they are still valid:
https://info.varnish-software.com/blog/backends-load-balancing
https://info.varnish-software.com/blog/backends-load-balancing-part-2

The first one goes through probes, and the second one explores directors,
including the fallback one.

Hope that helps

-- 
Guillaume Quintard


On Sat, Jul 4, 2020 at 7:14 AM hamidreza hosseini <hrhosseini at hotmail.com>
wrote:

> Hi,
> I want to have 2 or 3 backends in the Varnish config file but just one of
> them workes as an active backend and whenever my active backend failed ,
> the second backend become active and respond the requests. (In other hand,
> I dont want to have two backend for responding clients and just one of them
> works at the same time, and it check the health status of my active backend
> , whenever it is was unhealthy , varnish switch to the second or third
> backend.)
> Best Regards.
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200704/be130ed2/attachment-0001.html>

From hrhosseini at hotmail.com  Sat Jul  4 15:47:18 2020
From: hrhosseini at hotmail.com (hamidreza hosseini)
Date: Sat, 4 Jul 2020 15:47:18 +0000
Subject: solution for Active/Passive Backend
In-Reply-To: <CAJ6ZYQyANFJf+JFVUXFWO5yD1H+Fa+Nxe5d_dNrtuTpX3rgYjQ@mail.gmail.com>
References: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>,
 <CAJ6ZYQyANFJf+JFVUXFWO5yD1H+Fa+Nxe5d_dNrtuTpX3rgYjQ@mail.gmail.com>
Message-ID: <BYAPR16MB29354DC9D41D8B7E1DB88602D96B0@BYAPR16MB2935.namprd16.prod.outlook.com>

Thanks for your answer,
I read yor blog post, you wrote there that fallback director will check the health status of the servers and it will choose one of them that is healthy(First one) , so by this explanation i dont need to define the prob for my backends to understand that my backends are healthy or not, is it true?
is this config file enough for my purpose?
"
import directors;

backend alpha1 { .host = "192.168.0.101"; }
backend alpha2 { .host = "192.168.0.201"; }
backend err    { .host = "192.168.0.150"; }

sub vcl_int {
    new alpha_rr = directors.round_robin();
    alpha_rr.add_backend(alpha1);
    alpha_rr.add_backend(alpha2);

    new alpha_fb = directors.fallback();
    alpha_fb.add_backend(alpha_rr.backend());
    alpha_fb.add_backend(err);
}
"
Best Regards
________________________________
From: Guillaume Quintard <guillaume at varnish-software.com>
Sent: Saturday, July 4, 2020 8:11 AM
To: hamidreza hosseini <hrhosseini at hotmail.com>
Cc: varnish-misc at varnish-cache.org <varnish-misc at varnish-cache.org>
Subject: Re: solution for Active/Passive Backend

Hi,

You want to use probes and the fallback director.

Relevant documentation:
to define a probe:https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#probes
to attach it to backends: https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#backend-definition
the fallback director: https://varnish-cache.org/docs/6.4/reference/vmod_directors.html?highlight=fallback#directors-fallback

i also wrote these blog posts a long time ago, but they are still valid:
https://info.varnish-software.com/blog/backends-load-balancing
https://info.varnish-software.com/blog/backends-load-balancing-part-2

The first one goes through probes, and the second one explores directors, including the fallback one.

Hope that helps

--
Guillaume Quintard


On Sat, Jul 4, 2020 at 7:14 AM hamidreza hosseini <hrhosseini at hotmail.com<mailto:hrhosseini at hotmail.com>> wrote:
Hi,
I want to have 2 or 3 backends in the Varnish config file but just one of them workes as an active backend and whenever my active backend failed , the second backend become active and respond the requests. (In other hand, I dont want to have two backend for responding clients and just one of them works at the same time, and it check the health status of my active backend , whenever it is was unhealthy , varnish switch to the second or third backend.)
Best Regards.
_______________________________________________
varnish-misc mailing list
varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200704/5fc96bd0/attachment.html>

From guillaume at varnish-software.com  Sat Jul  4 15:52:13 2020
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Sat, 4 Jul 2020 08:52:13 -0700
Subject: solution for Active/Passive Backend
In-Reply-To: <BYAPR16MB29354DC9D41D8B7E1DB88602D96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
References: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
 <CAJ6ZYQyANFJf+JFVUXFWO5yD1H+Fa+Nxe5d_dNrtuTpX3rgYjQ@mail.gmail.com>
 <BYAPR16MB29354DC9D41D8B7E1DB88602D96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
Message-ID: <CAJ6ZYQymCKW2fD60VVkTZ9D=jeWR2QVSNw8T5iY26Jc3pJ1Z+A@mail.gmail.com>

Hi,

You will have to define a probe, otherwise Varnish will consider the
backend to be healthy by default. You would then be able to manually make
it sick, but for automatic health, you need probing.

Kind regards,
-- 
Guillaume Quintard


On Sat, Jul 4, 2020 at 8:47 AM hamidreza hosseini <hrhosseini at hotmail.com>
wrote:

> Thanks for your answer,
> I read yor blog post, you wrote there that fallback director will check
> the health status of the servers and it will choose one of them that is
> healthy(First one) , so by this explanation i dont need to define the prob
> for my backends to understand that my backends are healthy or not, is it
> true?
> is this config file enough for my purpose?
> "
> import directors;
>
> backend alpha1 { .host = "192.168.0.101"; }
> backend alpha2 { .host = "192.168.0.201"; }
> backend err    { .host = "192.168.0.150"; }
>
> sub vcl_int {
>     new alpha_rr = directors.round_robin();
>     alpha_rr.add_backend(alpha1);
>     alpha_rr.add_backend(alpha2);
>
>     new alpha_fb = directors.fallback();
>     alpha_fb.add_backend(alpha_rr.backend());
>     alpha_fb.add_backend(err);
> }
> "
> Best Regards
> ------------------------------
> *From:* Guillaume Quintard <guillaume at varnish-software.com>
> *Sent:* Saturday, July 4, 2020 8:11 AM
> *To:* hamidreza hosseini <hrhosseini at hotmail.com>
> *Cc:* varnish-misc at varnish-cache.org <varnish-misc at varnish-cache.org>
> *Subject:* Re: solution for Active/Passive Backend
>
> Hi,
>
> You want to use probes and the fallback director.
>
> Relevant documentation:
> to define a probe:
> https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#probes
> to attach it to backends:
> https://varnish-cache.org/docs/6.4/reference/vcl.html?highlight=probe#backend-definition
> the fallback director:
> https://varnish-cache.org/docs/6.4/reference/vmod_directors.html?highlight=fallback#directors-fallback
>
> i also wrote these blog posts a long time ago, but they are still valid:
> https://info.varnish-software.com/blog/backends-load-balancing
> https://info.varnish-software.com/blog/backends-load-balancing-part-2
>
> The first one goes through probes, and the second one explores directors,
> including the fallback one.
>
> Hope that helps
>
> --
> Guillaume Quintard
>
>
> On Sat, Jul 4, 2020 at 7:14 AM hamidreza hosseini <hrhosseini at hotmail.com>
> wrote:
>
> Hi,
> I want to have 2 or 3 backends in the Varnish config file but just one of
> them workes as an active backend and whenever my active backend failed ,
> the second backend become active and respond the requests. (In other hand,
> I dont want to have two backend for responding clients and just one of them
> works at the same time, and it check the health status of my active backend
> , whenever it is was unhealthy , varnish switch to the second or third
> backend.)
> Best Regards.
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200704/2fd73bbb/attachment.html>

From dridi at varni.sh  Sat Jul  4 18:43:22 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Sat, 4 Jul 2020 18:43:22 +0000
Subject: solution for Active/Passive Backend
In-Reply-To: <CAJ6ZYQymCKW2fD60VVkTZ9D=jeWR2QVSNw8T5iY26Jc3pJ1Z+A@mail.gmail.com>
References: <BYAPR16MB293597E9F1018B35E0702B4ED96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
 <CAJ6ZYQyANFJf+JFVUXFWO5yD1H+Fa+Nxe5d_dNrtuTpX3rgYjQ@mail.gmail.com>
 <BYAPR16MB29354DC9D41D8B7E1DB88602D96B0@BYAPR16MB2935.namprd16.prod.outlook.com>
 <CAJ6ZYQymCKW2fD60VVkTZ9D=jeWR2QVSNw8T5iY26Jc3pJ1Z+A@mail.gmail.com>
Message-ID: <CABoVN9DAzjtAfBtbMA+XNNMN4qh=oVCgZFW-+VZ_A1eNZgPuLQ@mail.gmail.com>

On Sat, Jul 4, 2020 at 3:54 PM Guillaume Quintard
<guillaume at varnish-software.com> wrote:
>
> Hi,
>
> You will have to define a probe, otherwise Varnish will consider the backend to be healthy by default. You would then be able to manually make it sick, but for automatic health, you need probing.

Alternatively one can also use vmod_saintmode and retry failed fetches.

Dridi

From meken at meken.com  Sat Jul 18 20:49:01 2020
From: meken at meken.com (Meken)
Date: Sun, 19 Jul 2020 04:49:01 +0800
Subject: VSM: Could not get hold of varnishd, is it running?
Message-ID: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>

I am running Ubuntu 20.04.

Recently upgrade of bash (apt update && apt upgrade) causes
varnishlog/varnishtop/varnishtop not working:
 <http://us.archive.ubuntu.com/ubuntu> http://us.archive.ubuntu.com/ubuntu
focal-updates/main amd64 bash amd64 5.0-6ubuntu1.1

varnishstat
.....
VSM: Could not get hold of varnishd, is it running?

Change to" sudo varnishstat" no use

(but varnish is running)

Tested on Varnish 6.2.1 also 6.4 master.

So it is a bug of Ubuntu or Varnish?

The only fix is to roll back to cancel the upgrade.

ps aux | grep varnish

root     2042323  0.0  0.0   9032   736 pts/0    S+   04:28   0:00 grep
--color=auto varnish

vcache   4055139  0.0  0.2  19148  5120 ?        SLs  Jul18   0:05
/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f
/etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p
thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p
feature=+http2 -s malloc,20G -a [::1]:6086,PROXY

vcache   4055284  0.0  4.1 4417784 84540 ?       SLl  Jul18   0:48
/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f
/etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p
thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p
feature=+http2 -s malloc,20G -a [::1]:6086,PROXY 

 

Any idea? Thanks!

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200719/a5e00f36/attachment.html>

From dridi at varni.sh  Mon Jul 20 07:15:05 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 20 Jul 2020 07:15:05 +0000
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
Message-ID: <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>

On Sat, Jul 18, 2020 at 8:50 PM Meken <meken at meken.com> wrote:
>
> I am running Ubuntu 20.04.
>
> Recently upgrade of bash (apt update && apt upgrade) causes varnishlog/varnishtop/varnishtop not working:
> http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 bash amd64 5.0-6ubuntu1.1
>
> varnishstat
> .....
> VSM: Could not get hold of varnishd, is it running?
>
> Change to" sudo varnishstat" no use
>
> (but varnish is running)
>
> Tested on Varnish 6.2.1 also 6.4 master.
>
> So it is a bug of Ubuntu or Varnish?
>
> The only fix is to roll back to cancel the upgrade.
>
> ps aux | grep varnish
>
> root     2042323  0.0  0.0   9032   736 pts/0    S+   04:28   0:00 grep --color=auto varnish
>
> vcache   4055139  0.0  0.2  19148  5120 ?        SLs  Jul18   0:05 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+http2 -s malloc,20G -a [::1]:6086,PROXY
>
> vcache   4055284  0.0  4.1 4417784 84540 ?       SLl  Jul18   0:48 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+http2 -s malloc,20G -a [::1]:6086,PROXY
>
>
>
> Any idea? Thanks!

Can you share the output of the following commands?

    find /var/lib/varnish -type f | sort
    hostname

I suspect that your machine's hostname changed. If I'm correct, that
you can't rely on your machine's name for some reason, then it's your
job to consistently use a stable -n option across all varnish* programs.

Dridi

From meken at meken.com  Mon Jul 20 07:31:33 2020
From: meken at meken.com (Meken)
Date: Mon, 20 Jul 2020 15:31:33 +0800
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
 <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
Message-ID: <001101d65e67$cc445100$64ccf300$@meken.com>

Hello,

Thank you for pointing out.

Actually I have found there are 2 hosting names:
/var/lib/varnish/hosting/_.pid
/var/lib/varnish/hosting/_.secret
/var/lib/varnish/hosting/vcl_boot.1591618254.762419/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593236167.441982/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593240709.080728/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593321686.422155/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593480415.481845/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593596331.767909/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593646740.490612/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593731130.396063/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593735970.554049/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593752115.898866/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593819341.925212/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593821348.845795/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593859036.905446/vgc.so
/var/lib/varnish/hosting/vcl_boot.1593936916.234738/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594102030.408020/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594102493.820495/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594102558.317889/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594115324.956808/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594256069.249118/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594263018.809147/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594276763.233978/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594513693.409623/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594709761.958055/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594759584.588062/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594807888.796914/vgc.c
/var/lib/varnish/hosting/vcl_boot.1594807888.796914/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594807889.098981/vgc.so
/var/lib/varnish/hosting/vcl_boot.1594808687.740858/vgc.so
/var/lib/varnish/hosting/vcl_boot.1595220966.259629/vgc.so
/var/lib/varnish/hosting/vmod_cache/_vmod_geoip2.d4f3e94eb0a40163792cb604b03f475f2793827043dc3f812e3867640adbc5ef
/var/lib/varnish/hosting/vmod_cache/_vmod_memcached.ba9f2e10f51787a29884e1314a9a5cc5797c7b07701180c691ed8dc35ea519a9
/var/lib/varnish/hosting/vmod_cache/_vmod_purge.c9c4dcec5374aa74bc575bf8eb4b14ea3a397cf7f9b76c92e61f6d445c272954
/var/lib/varnish/hosting/vmod_cache/_vmod_sec.3f2220cc1ca701039ece8fa1e9372a9c489be429f7bc034409b0e19bc444ee07
/var/lib/varnish/hosting/vmod_cache/_vmod_std.9af553a8dca884723194122f99d953c49f3196571879528d1e3a4cf485eb69db
/var/lib/varnish/hosting/vmod_cache/_vmod_std.e6809bfcaa7e0a8e8471aff746df13c28aa127a2129196b7111767d698410a92
/var/lib/varnish/hosting/vmod_cache/_vmod_vtc.74219daba3f1108c268976b885710bb561ad7ae6cfb3586395752577aa2fe026
/var/lib/varnish/hosting/_.vsm_child/_.index
/var/lib/varnish/hosting/_.vsm_child/_.Log.d266b469ee688702
/var/lib/varnish/hosting/_.vsm_child/_.Stat.00e7e8c4bb334857
/var/lib/varnish/hosting/_.vsm_child/_.Stat.1874be6262cc0a02
/var/lib/varnish/hosting/_.vsm_child/_.Stat.238cd87b80f5106e
/var/lib/varnish/hosting/_.vsm_child/_.Stat.25a115b0812f1035
/var/lib/varnish/hosting/_.vsm_child/_.Stat.2a9d8ae90aa04520
/var/lib/varnish/hosting/_.vsm_child/_.Stat.2ce901f81ba8674b
/var/lib/varnish/hosting/_.vsm_child/_.Stat.3574f9ee43d182e0
/var/lib/varnish/hosting/_.vsm_child/_.Stat.4011ed5c65c24b76
/var/lib/varnish/hosting/_.vsm_child/_.Stat.4761cd6c4a0762af
/var/lib/varnish/hosting/_.vsm_child/_.Stat.483db41d2228a967
/var/lib/varnish/hosting/_.vsm_child/_.Stat.58ec4019d9af72ce
/var/lib/varnish/hosting/_.vsm_child/_.Stat.6ac8e14abb95d172
/var/lib/varnish/hosting/_.vsm_child/_.Stat.6f8e7c3a423f6c35
/var/lib/varnish/hosting/_.vsm_child/_.Stat.763b18d8e7345576
/var/lib/varnish/hosting/_.vsm_child/_.Stat.77d454dd1ca35c5b
/var/lib/varnish/hosting/_.vsm_child/_.Stat.84b131352b10995e
/var/lib/varnish/hosting/_.vsm_child/_.Stat.84ef1d281d0eacb0
/var/lib/varnish/hosting/_.vsm_child/_.Stat.88193972776ea4a8
/var/lib/varnish/hosting/_.vsm_child/_.Stat.93683d94dfe8b49b
/var/lib/varnish/hosting/_.vsm_child/_.Stat.a29a5acbb13ff336
/var/lib/varnish/hosting/_.vsm_child/_.Stat.a54063898ad7a594
/var/lib/varnish/hosting/_.vsm_child/_.Stat.aa88295972a97fcc
/var/lib/varnish/hosting/_.vsm_child/_.Stat.ab13aaaa63a7590d
/var/lib/varnish/hosting/_.vsm_child/_.Stat.aff530520dda04f4
/var/lib/varnish/hosting/_.vsm_child/_.Stat.bf90f2d515755eb0
/var/lib/varnish/hosting/_.vsm_child/_.Stat.ccbd337d82f6f0ff
/var/lib/varnish/hosting/_.vsm_child/_.Stat.df6fae49485208f1
/var/lib/varnish/hosting/_.vsm_child/_.StatDoc.233471e63a82f29e
/var/lib/varnish/hosting/_.vsm_child/_.StatDoc.7a9121bef6364347
/var/lib/varnish/hosting/_.vsm_child/_.StatDoc.7f4e829390f4e010
/var/lib/varnish/hosting/_.vsm_child/_.StatDoc.cee2c5474f14f3ae
/var/lib/varnish/hosting/_.vsm_child/_.StatDoc.f755c6a94b3d1172
/var/lib/varnish/hosting/_.vsm_child/_.Stat.e55cc8f627f75977
/var/lib/varnish/hosting/_.vsm_child/_.VSC_cluster.c2883cff4bdf936e
/var/lib/varnish/hosting/_.vsm_mgt/_.Arg.540dee026edd092a
/var/lib/varnish/hosting/_.vsm_mgt/_.Arg.eb34a8d8e7955630
/var/lib/varnish/hosting/_.vsm_mgt/_.Arg.eeab20a2138302e8
/var/lib/varnish/hosting/_.vsm_mgt/_.index
/var/lib/varnish/hosting/_.vsm_mgt/_.Panic.5f9e79333501df4f
/var/lib/varnish/hosting/_.vsm_mgt/_.Params.3012301ec25172db
/var/lib/varnish/hosting/_.vsm_mgt/_.Stat.cd05e3a89836f99c
/var/lib/varnish/hosting/_.vsm_mgt/_.StatDoc.da0172c3844cf691
/var/lib/varnish/support/_.pid
/var/lib/varnish/support/vcl_boot.1593736744.546792/vgc.so
/var/lib/varnish/support/vcl_boot.1594871730.354112/vgc.so
/var/lib/varnish/support/vcl_boot.1594872103.186081/vgc.so
/var/lib/varnish/support/vcl_boot.1594872168.503624/vgc.so
/var/lib/varnish/support/vcl_boot.1594873897.854042/vgc.c
/var/lib/varnish/support/vcl_boot.1594873897.854042/vgc.so
/var/lib/varnish/support/vcl_boot.1594873970.453179/vgc.so
/var/lib/varnish/support/vcl_boot.1594876509.059029/vgc.so
/var/lib/varnish/support/vmod_cache/_vmod_geoip2.d4f3e94eb0a40163792cb604b03f475f2793827043dc3f812e3867640adbc5ef
/var/lib/varnish/support/vmod_cache/_vmod_memcached.ba9f2e10f51787a29884e1314a9a5cc5797c7b07701180c691ed8dc35ea519a9
/var/lib/varnish/support/vmod_cache/_vmod_purge.c9c4dcec5374aa74bc575bf8eb4b14ea3a397cf7f9b76c92e61f6d445c272954
/var/lib/varnish/support/vmod_cache/_vmod_sec.3f2220cc1ca701039ece8fa1e9372a9c489be429f7bc034409b0e19bc444ee07
/var/lib/varnish/support/vmod_cache/_vmod_std.9af553a8dca884723194122f99d953c49f3196571879528d1e3a4cf485eb69db
/var/lib/varnish/support/vmod_cache/_vmod_std.e6809bfcaa7e0a8e8471aff746df13c28aa127a2129196b7111767d698410a92
/var/lib/varnish/support/vmod_cache/_vmod_vtc.74219daba3f1108c268976b885710bb561ad7ae6cfb3586395752577aa2fe026
/var/lib/varnish/support/_.vsm_child/_.index
/var/lib/varnish/support/_.vsm_child/_.Log.0d7f44cb8f3a5d1b
/var/lib/varnish/support/_.vsm_child/_.Log.5f672d0f5c10f522
/var/lib/varnish/support/_.vsm_child/_.Stat.04e5741d57c00566
/var/lib/varnish/support/_.vsm_child/_.Stat.09283eb16bd580f1
/var/lib/varnish/support/_.vsm_child/_.Stat.0ba2e4045c53a967
/var/lib/varnish/support/_.vsm_child/_.Stat.0dc3a2c9c64789cc
/var/lib/varnish/support/_.vsm_child/_.Stat.1069abe01bd05172
/var/lib/varnish/support/_.vsm_child/_.Stat.13a0b0fe6e0ca24a
/var/lib/varnish/support/_.vsm_child/_.Stat.15e5b4513f3bccad
/var/lib/varnish/support/_.vsm_child/_.Stat.1a1e77f3537d50a5
/var/lib/varnish/support/_.vsm_child/_.Stat.1f8bcdebd50dce46
/var/lib/varnish/support/_.vsm_child/_.Stat.1fc7a3861f8915da
/var/lib/varnish/support/_.vsm_child/_.Stat.205137ca5b0d6e75
/var/lib/varnish/support/_.vsm_child/_.Stat.251d5917e3797596
/var/lib/varnish/support/_.vsm_child/_.Stat.263c03843f6c3127
/var/lib/varnish/support/_.vsm_child/_.Stat.2781f2c4fcadaf37
/var/lib/varnish/support/_.vsm_child/_.Stat.27fddc8a76c75afe
/var/lib/varnish/support/_.vsm_child/_.Stat.381a53de43f5d59c
/var/lib/varnish/support/_.vsm_child/_.Stat.41a98962a6deaaf9
/var/lib/varnish/support/_.vsm_child/_.Stat.42bc1b375a7bba8b
/var/lib/varnish/support/_.vsm_child/_.Stat.42f0cfdaf3052ba4
/var/lib/varnish/support/_.vsm_child/_.Stat.448ee9c322abe5aa
/var/lib/varnish/support/_.vsm_child/_.Stat.49030f0f527c2f7b
/var/lib/varnish/support/_.vsm_child/_.Stat.55c04b86b78fb54b
/var/lib/varnish/support/_.vsm_child/_.Stat.5a8b83284950827c
/var/lib/varnish/support/_.vsm_child/_.Stat.60632071ca31fbb3
/var/lib/varnish/support/_.vsm_child/_.Stat.62e0c25a09b57d36
/var/lib/varnish/support/_.vsm_child/_.Stat.63cbbc16613f41dd
/var/lib/varnish/support/_.vsm_child/_.Stat.667c8b85466044a9
/var/lib/varnish/support/_.vsm_child/_.Stat.668f4a89bf9ea4cd
/var/lib/varnish/support/_.vsm_child/_.Stat.6892c4b5c217fc86
/var/lib/varnish/support/_.vsm_child/_.Stat.69a303a09332c2a6
/var/lib/varnish/support/_.vsm_child/_.Stat.6d0295da6c7e4026
/var/lib/varnish/support/_.vsm_child/_.Stat.6f139f66d1556e35
/var/lib/varnish/support/_.vsm_child/_.Stat.7aef7d316e14c17d
/var/lib/varnish/support/_.vsm_child/_.Stat.8684b86feab43f8b
/var/lib/varnish/support/_.vsm_child/_.Stat.888a83242ead17b3
/var/lib/varnish/support/_.vsm_child/_.Stat.8fde8ab16971111e
/var/lib/varnish/support/_.vsm_child/_.Stat.92d42eab309c4675
/var/lib/varnish/support/_.vsm_child/_.Stat.94600744f8d4b542
/var/lib/varnish/support/_.vsm_child/_.Stat.98e6a37d304956cf
/var/lib/varnish/support/_.vsm_child/_.Stat.997e31fae07bec89
/var/lib/varnish/support/_.vsm_child/_.Stat.9ab58bc666f5bba4
/var/lib/varnish/support/_.vsm_child/_.Stat.9c56793dc78624aa
/var/lib/varnish/support/_.vsm_child/_.Stat.a3769f31af4d4a56
/var/lib/varnish/support/_.vsm_child/_.Stat.aeaa32e7043a49f0
/var/lib/varnish/support/_.vsm_child/_.Stat.c4f0776f732e44cc
/var/lib/varnish/support/_.vsm_child/_.Stat.c597cdb86d76d7e2
/var/lib/varnish/support/_.vsm_child/_.Stat.ca6a8a3a10c35b97
/var/lib/varnish/support/_.vsm_child/_.Stat.d2280028348f15fa
/var/lib/varnish/support/_.vsm_child/_.Stat.d49bb6303364fc11
/var/lib/varnish/support/_.vsm_child/_.Stat.d7c51ba5c7127a00
/var/lib/varnish/support/_.vsm_child/_.Stat.dc712cf00b3666e6
/var/lib/varnish/support/_.vsm_child/_.StatDoc.3e1ceffd24df5a18
/var/lib/varnish/support/_.vsm_child/_.StatDoc.54904901d6b74897
/var/lib/varnish/support/_.vsm_child/_.StatDoc.54cd1302167ba000
/var/lib/varnish/support/_.vsm_child/_.StatDoc.5641140ea7bd59ad
/var/lib/varnish/support/_.vsm_child/_.StatDoc.7633d1248aa6017b
/var/lib/varnish/support/_.vsm_child/_.StatDoc.78c9be3d7a9ce6ff
/var/lib/varnish/support/_.vsm_child/_.StatDoc.7f4a0b837ca94f0a
/var/lib/varnish/support/_.vsm_child/_.StatDoc.c053791bd40907d0
/var/lib/varnish/support/_.vsm_child/_.StatDoc.c6460525e8aad955
/var/lib/varnish/support/_.vsm_child/_.StatDoc.f0b85ae236385aeb
/var/lib/varnish/support/_.vsm_child/_.Stat.e4b78a3cd5feacba
/var/lib/varnish/support/_.vsm_child/_.Stat.f697d3510bd1ae42
/var/lib/varnish/support/_.vsm_child/_.Stat.f87c0de19b04d006
/var/lib/varnish/support/_.vsm_child/_.Stat.fa563f8367737d1a
/var/lib/varnish/support/_.vsm_child/_.Stat.fc8280663c3c7a40
/var/lib/varnish/support/_.vsm_child/_.Stat.fcb623de50ff122f
/var/lib/varnish/support/_.vsm_child/_.Stat.ff13927f8a90a16d
/var/lib/varnish/support/_.vsm_child/_.VSC_cluster.02cb52f34a27a893
/var/lib/varnish/support/_.vsm_child/_.VSC_cluster.03933e00c82bc1d1
/var/lib/varnish/support/_.vsm_mgt/_.Arg.4eaa244519cb7a9a
/var/lib/varnish/support/_.vsm_mgt/_.Arg.577eb07c6bc135a2
/var/lib/varnish/support/_.vsm_mgt/_.Arg.7f29700cce51573c
/var/lib/varnish/support/_.vsm_mgt/_.Arg.aa405a409fa7bf72
/var/lib/varnish/support/_.vsm_mgt/_.Arg.f5af18d04d4747e8
/var/lib/varnish/support/_.vsm_mgt/_.Arg.f6f835e049452613
/var/lib/varnish/support/_.vsm_mgt/_.index
/var/lib/varnish/support/_.vsm_mgt/_.Panic.34f80bfd2fbe8660
/var/lib/varnish/support/_.vsm_mgt/_.Panic.3db14e7765aec3e9
/var/lib/varnish/support/_.vsm_mgt/_.Params.42de3b754cf4c5a9
/var/lib/varnish/support/_.vsm_mgt/_.Params.d698b52111b56e29
/var/lib/varnish/support/_.vsm_mgt/_.Stat.0c4c4a8b3ed63264
/var/lib/varnish/support/_.vsm_mgt/_.Stat.cee2e408df941cf1
/var/lib/varnish/support/_.vsm_mgt/_.StatDoc.422159a36029a74a
/var/lib/varnish/support/_.vsm_mgt/_.StatDoc.452b53c7cdc2e613

So I rm -r /var/lib/varnish/support (it is wrong hostname), but nothing changed?


Best regards,



Hu

-----Original Message-----
From: Dridi Boukelmoune <dridi at varni.sh> 
Sent: Monday, July 20, 2020 3:15 PM
To: Meken <meken at meken.com>
Cc: varnish-misc <varnish-misc at varnish-cache.org>
Subject: Re: VSM: Could not get hold of varnishd, is it running?

On Sat, Jul 18, 2020 at 8:50 PM Meken <meken at meken.com> wrote:
>
> I am running Ubuntu 20.04.
>
> Recently upgrade of bash (apt update && apt upgrade) causes varnishlog/varnishtop/varnishtop not working:
> http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 bash 
> amd64 5.0-6ubuntu1.1
>
> varnishstat
> .....
> VSM: Could not get hold of varnishd, is it running?
>
> Change to" sudo varnishstat" no use
>
> (but varnish is running)
>
> Tested on Varnish 6.2.1 also 6.4 master.
>
> So it is a bug of Ubuntu or Varnish?
>
> The only fix is to roll back to cancel the upgrade.
>
> ps aux | grep varnish
>
> root     2042323  0.0  0.0   9032   736 pts/0    S+   04:28   0:00 grep --color=auto varnish
>
> vcache   4055139  0.0  0.2  19148  5120 ?        SLs  Jul18   0:05 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+http2 -s malloc,20G -a [::1]:6086,PROXY
>
> vcache   4055284  0.0  4.1 4417784 84540 ?       SLl  Jul18   0:48 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -t 120 -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+http2 -s malloc,20G -a [::1]:6086,PROXY
>
>
>
> Any idea? Thanks!

Can you share the output of the following commands?

    find /var/lib/varnish -type f | sort
    hostname

I suspect that your machine's hostname changed. If I'm correct, that you can't rely on your machine's name for some reason, then it's your job to consistently use a stable -n option across all varnish* programs.

Dridi


From dridi at varni.sh  Mon Jul 20 08:00:48 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 20 Jul 2020 08:00:48 +0000
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <001101d65e67$cc445100$64ccf300$@meken.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
 <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
 <001101d65e67$cc445100$64ccf300$@meken.com>
Message-ID: <CABoVN9Bo5orMSNKfdirCYX1bHWhZrp3FFfvj-o7j+sx9rtO6RQ@mail.gmail.com>

> So I rm -r /var/lib/varnish/support (it is wrong hostname), but nothing changed?

You didn't share the output of the hostname command.

Dridi

From meken at meken.com  Mon Jul 20 08:12:43 2020
From: meken at meken.com (Meken)
Date: Mon, 20 Jul 2020 16:12:43 +0800
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <CABoVN9Bo5orMSNKfdirCYX1bHWhZrp3FFfvj-o7j+sx9rtO6RQ@mail.gmail.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
 <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
 <001101d65e67$cc445100$64ccf300$@meken.com>
 <CABoVN9Bo5orMSNKfdirCYX1bHWhZrp3FFfvj-o7j+sx9rtO6RQ@mail.gmail.com>
Message-ID: <001201d65e6d$8c4ef7c0$a4ece740$@meken.com>

Sorry!

root at hosting:/var/lib/varnish# hostname 
hosting

Best regards,



Hu

-----Original Message-----
From: Dridi Boukelmoune <dridi at varni.sh> 
Sent: Monday, July 20, 2020 4:01 PM
To: Meken <meken at meken.com>
Cc: varnish-misc <varnish-misc at varnish-cache.org>
Subject: Re: VSM: Could not get hold of varnishd, is it running?

> So I rm -r /var/lib/varnish/support (it is wrong hostname), but nothing changed?

You didn't share the output of the hostname command.

Dridi


From dridi at varni.sh  Mon Jul 20 08:45:30 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 20 Jul 2020 08:45:30 +0000
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <001201d65e6d$8c4ef7c0$a4ece740$@meken.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
 <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
 <001101d65e67$cc445100$64ccf300$@meken.com>
 <CABoVN9Bo5orMSNKfdirCYX1bHWhZrp3FFfvj-o7j+sx9rtO6RQ@mail.gmail.com>
 <001201d65e6d$8c4ef7c0$a4ece740$@meken.com>
Message-ID: <CABoVN9AKib7Dx8t37HC0bHs2mgUFO-++fUk5iKrCTTcJR0iuFA@mail.gmail.com>

On Mon, Jul 20, 2020 at 8:12 AM Meken <meken at meken.com> wrote:
>
> Sorry!
>
> root at hosting:/var/lib/varnish# hostname
> hosting

So now the problem is that you removed the /var/lib/varnish/support
directory and we lost the opportunity to inspect it ?\_(?)_/?

Does the PID in /var/lib/varnish/hosting/_.pid match the root varnishd
process in the command output below?

    ps f -C varnishd -C cache-main

Dridi

From meken at meken.com  Mon Jul 20 08:55:34 2020
From: meken at meken.com (Meken)
Date: Mon, 20 Jul 2020 16:55:34 +0800
Subject: VSM: Could not get hold of varnishd, is it running?
In-Reply-To: <CABoVN9AKib7Dx8t37HC0bHs2mgUFO-++fUk5iKrCTTcJR0iuFA@mail.gmail.com>
References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com>
 <CABoVN9BB5gTEi3jzZcR6-E70oX0aEqEnEtf57bhJRGN+S=sx-w@mail.gmail.com>
 <001101d65e67$cc445100$64ccf300$@meken.com>
 <CABoVN9Bo5orMSNKfdirCYX1bHWhZrp3FFfvj-o7j+sx9rtO6RQ@mail.gmail.com>
 <001201d65e6d$8c4ef7c0$a4ece740$@meken.com>
 <CABoVN9AKib7Dx8t37HC0bHs2mgUFO-++fUk5iKrCTTcJR0iuFA@mail.gmail.com>
Message-ID: <001301d65e73$88b71c40$9a2554c0$@meken.com>

Oh.... ?

ps f -C varnishd -C cache-main
    PID TTY      STAT   TIME COMMAND
 355807 ?        SLs    0:00 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+http2 -
 355974 ?        SLl    4:03  \_ /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -p thread_pool_min=500 -p thread_pool_max=5000 -p thread_pool_stack=4M -p feature=+htt

I guess the reason is that a couple of months ago I copied system files using rsync from another host (support), in an event of loss, so something messed up.  But this conflicts just showed it up now when I upgrade bash.


Best regards,



Hu

-----Original Message-----
From: Dridi Boukelmoune <dridi at varni.sh> 
Sent: Monday, July 20, 2020 4:46 PM
To: Meken <meken at meken.com>
Cc: varnish-misc <varnish-misc at varnish-cache.org>
Subject: Re: VSM: Could not get hold of varnishd, is it running?

On Mon, Jul 20, 2020 at 8:12 AM Meken <meken at meken.com> wrote:
>
> Sorry!
>
> root at hosting:/var/lib/varnish# hostname hosting

So now the problem is that you removed the /var/lib/varnish/support directory and we lost the opportunity to inspect it ?\_(?)_/?

Does the PID in /var/lib/varnish/hosting/_.pid match the root varnishd process in the command output below?

    ps f -C varnishd -C cache-main

Dridi


From batanun at hotmail.com  Thu Jul 30 19:28:58 2020
From: batanun at hotmail.com (Batanun B)
Date: Thu, 30 Jul 2020 19:28:58 +0000
Subject: Detect request coalescing?
Message-ID: <AM7PR08MB541691937AEE0326ED288112AC710@AM7PR08MB5416.eurprd08.prod.outlook.com>

Just a quick question that I wasn't able to find any information on using regular google searches. Is it possible to detect request coalescing somehow? Meaning that, when looking at the response headers, can I somehow see that the request had to wait for another request for the same resource to finish, before this request could return? Can I somehow detect that in VCL, and add a custom header with that information?

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200730/f4c7eb62/attachment.html>

From dridi at varni.sh  Fri Jul 31 05:56:49 2020
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 31 Jul 2020 05:56:49 +0000
Subject: Detect request coalescing?
In-Reply-To: <AM7PR08MB541691937AEE0326ED288112AC710@AM7PR08MB5416.eurprd08.prod.outlook.com>
References: <AM7PR08MB541691937AEE0326ED288112AC710@AM7PR08MB5416.eurprd08.prod.outlook.com>
Message-ID: <CABoVN9DQ6=Te27GV8RdEJnK0KwO9A8bnpU2ANJAV8bxoFZpugw@mail.gmail.com>

On Thu, Jul 30, 2020 at 7:30 PM Batanun B <batanun at hotmail.com> wrote:
>
> Just a quick question that I wasn't able to find any information on using regular google searches. Is it possible to detect request coalescing somehow? Meaning that, when looking at the response headers, can I somehow see that the request had to wait for another request for the same resource to finish, before this request could return? Can I somehow detect that in VCL, and add a custom header with that information?

Hi,

I don't think you can do that.

Dridi

From geoff at uplex.de  Fri Jul 31 06:24:14 2020
From: geoff at uplex.de (Geoff Simmons)
Date: Fri, 31 Jul 2020 08:24:14 +0200
Subject: Detect request coalescing?
In-Reply-To: <AM7PR08MB541691937AEE0326ED288112AC710@AM7PR08MB5416.eurprd08.prod.outlook.com>
References: <AM7PR08MB541691937AEE0326ED288112AC710@AM7PR08MB5416.eurprd08.prod.outlook.com>
Message-ID: <d0aadb88-3ebd-4789-61c9-76e6c5f33f2c@uplex.de>

On 7/30/20 21:28, Batanun B wrote:
> Just a quick question that I wasn't able to find any information on
> using regular google searches. Is it possible to detect request
> coalescing somehow? Meaning that, when looking at the response headers,
> can I somehow see that the request had to wait for another request for
> the same resource to finish, before this request could return? Can I
> somehow detect that in VCL, and add a custom header with that information?

Client request logs will include Timestamp:WaitingList when that
happens. The timestamp isn't there if the request didn't have to wait,
and if it is, the timestamp tells you how long.

If your goal is to gather information about request coalescing, you cn
get it by scanning the log. If you need to know about it at runtime for
further request processing, then no I don't think there's anything for
that in VCL.


HTH,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20200731/4f93cadb/attachment.bin>