Weird SIGQUIT exception when combined with Docker's PHP fpm-buster image

[luislavena]

Hello,

First and most important, thank you for creating and making supercronic available to the world!

I'm trying to add supercronic to Docker container based on official Docker PHP one, and noticed that when supercronic is launched, either as entrypoint or via sh exec, the following exception is shown when trying to docker stop that container:

SIGQUIT: quit
PC=0x465601 m=0 sigcode=0

goroutine 0 [idle]:
runtime.futex(0xe45ca8, 0x80, 0x0, 0x0, 0x0, 0x7ffe00000000, 0x439e03, 0xc000080148, 0x7ffeddb51438, 0x40ac0f, ...)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/sys_linux_amd64.s:567 +0x21
runtime.futexsleep(0xe45ca8, 0x7ffe00000000, 0xffffffffffffffff)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/os_linux.go:45 +0x46
runtime.notesleep(0xe45ca8)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/lock_futex.go:151 +0x9f
runtime.stoplockedm()
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/proc.go:1977 +0x88
runtime.schedule()
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/proc.go:2460 +0x4a6
runtime.park_m(0xc0002c2600)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/proc.go:2696 +0x9d
runtime.mcall(0x0)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/asm_amd64.s:318 +0x5b

goroutine 1 [chan receive]:
main.main()
        /home/travis/gopath/src/github.com/aptible/supercronic/main.go:156 +0x98c

goroutine 39 [select]:
github.com/aptible/supercronic/cron.startFunc.func1(0xc0004f3db0, 0xe44b40, 0xa98640, 0xc0004bda40, 0xc00054e1c0, 0xaa2c60, 0xc0004c9440, 0xc0004eddd0, 0xc0004edd00)
        /home/travis/gopath/src/github.com/aptible/supercronic/cron/cron.go:182 +0x46c
created by github.com/aptible/supercronic/cron.startFunc
        /home/travis/gopath/src/github.com/aptible/supercronic/cron/cron.go:158 +0xbb

goroutine 40 [syscall]:
os/signal.signal_recv(0x0)
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/runtime/sigqueue.go:147 +0x9c
os/signal.loop()
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.Notify.func1
        /home/travis/.gimme/versions/go1.14.4.linux.amd64/src/os/signal/signal.go:127 +0x44

rax    0xca
rbx    0xe45b60
rcx    0x465603
rdx    0x0
rdi    0xe45ca8
rsi    0x80
rbp    0x7ffeddb51400
rsp    0x7ffeddb513b8
r8     0x0
r9     0x0
r10    0x0
r11    0x286
r12    0xff
r13    0x0
r14    0xa87be6
r15    0x0
rip    0x465601
rflags 0x286
cs     0x33
fs     0x0
gs     0x0

I was able to reduce the test scenario to the following Dockerfile:

FROM php:8.0-fpm-buster

# ---
# Setup Supercronic to run cron jobs
#
# Ref: https://github.com/aptible/supercronic

ENV SUPERCRONIC_VERSION=v0.1.12 \
      SUPERCRONIC_SHA1SUM=048b95b48b708983effb2e5c935a1ef8483d9e3e

RUN set -eux; \
    cd /tmp; \
    { \
        curl --fail -Lo supercronic https://github.com/aptible/supercronic/releases/download/${SUPERCRONIC_VERSION}/supercronic-linux-amd64; \
        echo "${SUPERCRONIC_SHA1SUM} *supercronic" | sha1sum -c - >/dev/null 2>&1; \
        chmod +x supercronic; \
        mv supercronic /usr/local/bin/supercronic; \
    };

# ---
# Copy crontab

COPY ./echo.crontab /etc/cron.d/echo

# ---
# Entrypoint

ENTRYPOINT ["/usr/local/bin/supercronic"]
CMD ["-passthrough-logs", "/etc/cron.d/echo"]

# echo.crontab
* * * * * echo "Hello!"

While PHP container is based on debian:buster-slim, I was not able to reproduce this scenario when using that image, however, This also works with cli-buster image, which makes things more tricky to investigate. I'm not proficient in Go in order to deeper debug this and report to Docker's official tracker.

Any hint that could help me debug this further?

Thank you in advance for your time.

❤️ ❤️ ❤️

[dudz94]

Hello,

I have exactly the same issue with a PHP image : php:7.4-fpm-alpine
Do you have an idea about this error ?

Thank you and thank for your amazing tool !

[blackmou5e]

Hello,
Found workaround for this issue:

1. use dumb-init

ENTRYPOINT: ["dumb-init", "--rewrite", "3:15", "--"]
CMD: ["supercronic", "/etc/crond.d/echo"]

Basically, we remaping SIGQUIT to SIGTERM here, because of supercronic (according to this line) doesn't handling anything beyond SIGTERM, SIGINT and SIGUSR2.

Reproduced error in almost all reasonable versions of php:xx-fpm images, with all available distros.
This fix worked in all of them.

I can't wrap my head around whats happening in php images, but it looks like it's not a supercronic problem, php dockerimage maintainers must be done something to inflict this behaviour. As far as I know, php-fpm can't handle SIGTERM properly (well, I believe it can, but it's not implemented for any reason), so they are sticking to SIGQUIT for graceful shutdown or something.

[UserNotFound]

I can't wrap my head around whats happening in php images, but it looks like it's not a supercronic problem, php dockerimage maintainers must be done something to inflict this behaviour. As far as I know, php-fpm can't handle SIGTERM properly (well, I believe it can, but it's not implemented for any reason), so they are sticking to SIGQUIT for graceful shutdown or something.

PHP images just set STOPSIGNAL SIGQUIT in their Dockerfile here.

Thanks for the PR, I'll take a look at it now.

[blackmou5e]

Thanks a lot, I've probably just missed that instruction in their Dockerfile.

[UserNotFound]

https://github.com/aptible/supercronic/releases/tag/v0.2.29