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: 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: 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: References: Message-ID: 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 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: 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: References: , Message-ID: 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 Sent: Saturday, July 4, 2020 8:11 AM To: hamidreza hosseini Cc: 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 > 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: 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: References: Message-ID: 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 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 > *Sent:* Saturday, July 4, 2020 8:11 AM > *To:* hamidreza hosseini > *Cc:* 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 > 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: 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: References: Message-ID: On Sat, Jul 4, 2020 at 3:54 PM Guillaume Quintard 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 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: 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: On Sat, Jul 18, 2020 at 8:50 PM Meken 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: References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.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 Sent: Monday, July 20, 2020 3:15 PM To: Meken Cc: varnish-misc Subject: Re: VSM: Could not get hold of varnishd, is it running? On Sat, Jul 18, 2020 at 8:50 PM Meken 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> <001101d65e67$cc445100$64ccf300$@meken.com> Message-ID: > 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: References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com> <001101d65e67$cc445100$64ccf300$@meken.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 Sent: Monday, July 20, 2020 4:01 PM To: Meken Cc: varnish-misc 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> <001101d65e67$cc445100$64ccf300$@meken.com> <001201d65e6d$8c4ef7c0$a4ece740$@meken.com> Message-ID: On Mon, Jul 20, 2020 at 8:12 AM Meken 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: References: <005b01d65d44$deb4f9d0$9c1eed70$@meken.com> <001101d65e67$cc445100$64ccf300$@meken.com> <001201d65e6d$8c4ef7c0$a4ece740$@meken.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 Sent: Monday, July 20, 2020 4:46 PM To: Meken Cc: varnish-misc Subject: Re: VSM: Could not get hold of varnishd, is it running? On Mon, Jul 20, 2020 at 8:12 AM Meken 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: 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: 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: References: Message-ID: On Thu, Jul 30, 2020 at 7:30 PM 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? 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: References: Message-ID: 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: