Signal handing in PHP

[adamquaile]

Hi,

I'm not sure if this is an issue with my setup, honcho or php, but maybe you can help..?

I have a Procfile with

caddy: PYTHONUNBUFFERED=true /usr/sbin/caddy
php: PYTHONUNBUFFERED=true /usr/local/sbin/php-fpm -F

It runs correctly, but it won't terminate the php process. When I hit Ctrl-c on the docker run command, I get this:

22:31:53 system  | caddy.1 started (pid=8)
22:31:53 system  | php.1 started (pid=9)
22:31:53 caddy.1 | Activating privacy features... done.
22:31:53 caddy.1 | :80
22:31:53 php.1   | [24-May-2017 22:31:53] NOTICE: fpm is running, pid 13
22:31:53 php.1   | [24-May-2017 22:31:53] NOTICE: ready to handle connections
^C22:32:03 system  | SIGINT received
22:32:03 system  | sending SIGTERM to caddy.1 (pid 8)
22:32:03 system  | sending SIGTERM to php.1 (pid 9)
22:32:03 system  | caddy.1 stopped (rc=-15)
22:32:08 system  | sending SIGKILL to php.1 (pid 9)
22:32:08 system  | sending SIGKILL to php.1 (pid 9)
22:32:08 system  | sending SIGKILL to php.1 (pid 9)
22:32:08 system  | sending SIGKILL to php.1 (pid 9)
22:32:09 system  | sending SIGKILL to php.1 (pid 9)
22:32:09 system  | sending SIGKILL to php.1 (pid 9)
22:32:09 system  | sending SIGKILL to php.1 (pid 9)
22:32:09 system  | sending SIGKILL to php.1 (pid 9)
22:32:09 system  | sending SIGKILL to php.1 (pid 9)

The SIGKILL line goes on indefinitely. I'm not sure if php is somehow restarting itself, or where to look. Any pointers where to look to debug. I'm using honcho v1.0.1.

Thanks!

[adamquaile]

So, it looks like in this case the actual php-fpm process that correctly handles signals is pid 13, as printed by php, but honcho thinks it is 9, which is some kind of shell invocation wrapping the process like this: /bin/sh -c PYTHONUNBUFFERED=true /usr/local/sbin/php-fpm -F.

[nickstenning]

Hmm, yes. Honcho currently runs processes in a subshell, and the shell won't forward that signal to child processes.

This is mostly a historical artifact, and while I don't remember the details I think it was some combination of a) Foreman did something similar, b) it was a straightforward way of allowing "shell-like" syntax (including $DOLLAR_EXPANSION and ENVVAR=value command arg1 arg2) in the Procfile, and c) I didn't know any better.

The problem is that (as you've discovered) this can be very confusing. The exact behaviour will differ from system to system and from Procfile to Procfile due to the way that common shells interpret the "-c" argument. Specifically, bash and recent versions of dash will optimise away the subshell by prefixing the last command in the argument to -c with exec. Older versions of dash don't do this, so the subshell stays. I think that's what's happening in your case.

Can you tell me what /bin/sh is on your system? And at what version?

[minhdanh]

I'm having the same problem. Here's some info:

/ # which sh
/bin/sh

/ # ls -l /bin/sh
lrwxrwxrwx    1 root     root            12 Jan  9 19:37 /bin/sh -> /bin/busybox

/ # sh --help
BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.

Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]

Unix shell interpreter