Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signal handing in PHP #193

Open
adamquaile opened this issue May 27, 2017 · 3 comments
Open

Signal handing in PHP #193

adamquaile opened this issue May 27, 2017 · 3 comments

Comments

@adamquaile
Copy link

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
Copy link
Author

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
Copy link
Owner

nickstenning commented Sep 18, 2017

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
Copy link

minhdanh commented Mar 24, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants