Graceful shutdown

[ghost]

This change attempts to solve #92. Once the shell scripts have bootstrapped the container, they are no longer required. I've added exec to both the shell scripts so that the fluentd process replaces them instead of becoming a child process of them.

It seemed reasonable to add exec to entrypoint.sh. It didn't feel as good when adding the exec to the CMD. I hope if anyone is overriding the CMD that they are aware they might be breaking graceful shutdown. What do you think?

I repeated my tests with one of the containers I've built from this branch.

Did we get rid of those sh processes?

# docker build -t fluentd-graceful-shutdown-fix .
# docker run -d --name fluentd fluentd-graceful-shutdown-fix
# docker exec fluentd pstree -p
entrypoint.sh(1)---fluentd(7)---fluentd(16)

We can see that fluentd is a child of PID1 now, so it should be managed by dumb-init.

What happens when we stop it?

# strace -e trace=signal $(docker top fluentd | tail -n +2 | awk ' { x=x" -p "
$1 } END { print x }') 2>&1 | grep "+++" > /tmp/trace &
# docker stop fluentd
fluentd
[1]+  Done                       strace -e trace=signal $(...) 2>&1 | grep "+++" 1>/tmp/trace
# cat /tmp/trace 
[pid 31164] +++ exited with 0 +++
[pid 31156] +++ exited with 0 +++
+++ exited with 0 +++

We can see that the fluentd processes exited cleanly.

[repeatedly]

@ValFadeev @atombender Do you see any problem for this patch?

[ValFadeev]

I think it's a great observation and a neat fix. The whole idea with using dumb-init was to achieve proper signal forwarding. However, it appears that the scripts are indeed getting in the way, and it would definitely not be appropriate to try to implement signal forwarding by hand (as it destroys the purpose of dumb-init wrapping)

[ghost]

Is there anything more I can do to help?

How about a picture of a cat in a sink?

[repeatedly]

Sorry for the delay. Just merged. Thanks 👍