Optionally send SIGTERM after reload.

[brndnmtthws]

This is to address issues #5, #71, #267, #276, and #318.

[h0tbird]

What is the purpose of & at the end of this line? The sleep runs in foreground and the kill runs in background, is that intended?

[brndnmtthws]

I don't believe that's the case. Test it yourself:

$ sleep 5s && echo finished &

[lloesche]

& and && are both posix shell pipeline separators. && executes sequentially until a nonzero status. & executes in parallel. If the purpose of the code is to wait $HAPROXY_RELOAD_SIGTERM_DELAY seconds before killing $HAPROXY_PIDS that's what it'll do, if it's parent run is still executing after the delay. If run was for whatever reason killed/restarted in the meantime the kill won't be executed.

Edit: Actually the kill might get executed depending on how the parent reaps it's children. I.e. in case of this bash script whether shopt huponexit is on or off. Likely also dependent on how runsv behaves.

[h0tbird]

So sleep and kill are sequentially executed but kill runs in parallel with the parent. I guess my real question is: How will this affect the overall time it takes to perform a zdd deploy?

[brndnmtthws]

That's right. If you set the delay to 5m, then the old HAProxy processes will get reaped after 5 minutes, no matter what (and the deploy should proceed).

[h0tbird]

Ok, I was hoping for zdd to handle the killing of old HAProxy asynchronously but I don't know if this is doable because it might lead to a corrupted list of listeners.

[ajays20078]

• Is this PR applicable only when we explicitly specify the reload command? Because the reload function here still uses default commands to reload if we don't specify anything explicitly.
• Also we need to explicitely specify the haproxy config file path as /marathon-lb/haproxy.cfg as per this ?

[brndnmtthws]

Yeah, this PR will only affect people who run MLB using the Docker image, or the built-in run script. I'll fix the haproxy.cfg thing in another PR.