Hi Corey, On Wed, Jun 25, 2014 at 12:05:59AM -0700, Corey Osman wrote: > Hi, > > I am using a custom 200 response file so that my upstream load balancer can > determine if my haproxy instance is operating correctly. > > errorfile 200 /home/haproxy/responses/200_resp.http > > Additionally I am using the monitor-uri /healthcheck. > > So when my upstream load balancer calls haproxyhost:port/healthcheck haproxy > will return the contents of the 200_resp.http file. > > This all works fine, however if I change the contents of the 200 response > file when haproxy is running I have noticed that haproxy is actually caching > this file. > > The caching part is fine, however in order for haproxy to see the updated > response file I must restart/reload haproxy so it picks up the new contents. > > You might be asking why am I changing this file? Well basically if I need to > perform rolling restarts on my haproxy instances I need a method of signaling > the upstream load balancer health check > to remove the haproxy instance from the available pool. So if I change the > contents of the 200 response I can basically automatically remove the haproxy > instance from the pool and traffic will no longer flow to > the haproxy instance. However, because haproxy caches this file I need to > restart/reload haproxy. I would like to not have to perform this restart > though. > > Is there any way to signal haproxy to invalidate the error file cache and > reread the errorfiles without restarting?
No, but you need to be aware that haproxy is not a file server, but a load balancer. It reads *all* of its configuration upon startup, is supposed to be chrooted and to drop its privileges, then it does not have any more access to the file system. > Can this be done through the stats socket? > > Is anybody else doing this and have a better method? Normally you're supposed to do this using "monitor-fail if ...". It will replace the 200 with the 500 based on a condition that you're free to determine. Hoping this helps, Willy
