You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ahh, OK. Yes, Chaperone will probably not notice the change in PID. When you specify a pidfile, Chaperone uses the pidfile only at process start-up time. It waits for the pidfile to appear before considering the process started, and when it sees the pidfile, it ignores the PID that was handed out by the process start-up, assuming that the new PID is the one. It's likely that when haproxy "generates a new PID" it is also terminating the old process, which chaperone is notified about. If it's configured to restart the service, it may actually attempt that. However, it sounds like haproxy is a special case. I wonder if it would make sense to use a "wrapper" script which runs haproxy, and have Chaperone run the wrapper script?
haproxy supports lightweight restarts which generate a new pid and take over the work of the previous process.
In this case, the active PID changes, but I've seen chaperone not updating the active pid when given a pidfile.
(sometimes it seems to honor the change, othertimes not)
Any clue on a timer what chaperone looks at the pid file?
The text was updated successfully, but these errors were encountered: