Don't deregister on SIGHUP

[activeshadow]

When a SIGHUP is sent to a container (ie. using something like docker kill -s HUP container-ID), the container is deregistered, but never reregistered, even though the container is still running.

My use case is with Nginx and docker-gen running in separate containers. I'm using an Nginx container to proxy requests to one or more API servers running in containers, and I'm using docker-gen to monitor for new API server containers in order to update and reload (via SIGHUP) the Nginx config. See here for more details regarding this use case.

I'm using registrator to make my Nginx proxy container available via my Consul-based DNS server, and find that when new API server containers are added the DNS entry for the Nginx proxy goes away. I can restart the Nginx proxy via docker restart and it shows back up again.

I suppose the feature requested in #128 could be a fix for this, but am wondering if the SIGHUP event can be handled directly instead.

[mgood]

Well, the Docker "kill" event doesn't indicate which signal was sent, so we can't handle it specially. However, due to some other changes with the "kill" event in Docker 1.8, it's become clear that checking for the "kill" event isn't really a good way to know that the process was intentionally terminated.

Instead, I was going to change it to check the exit status to see if it was terminated via a signal.

[JohnyDays]

Just showing that I've encountered this as well, and @mgood's fix would work for me. Have you started work on this? If not, I could take a stab at it

[JohnyDays]

Would it not be fine to just check for the die event? Since if you docker kill a container with the intent to terminate it, docker will eventually just send SIGKILL and the die event will be triggered

[mgood]

@JohnyDays yes, this uses the "die" event, but for the flag -deregister=on-success we also need to check if the container was intentionally killed with a signal, or terminated with an error code. The PR above distinguishes them to keep that behavior.

[JohnyDays]

Oh, thanks for the clarification. Wasn't really aware of that flag since i'd never used it. I'll check out your PR tomorrow in my fork and replace my temporary fix code, i'll post some feedback there.