upstart script ignores some php-fpm.conf parameters, cannot be bypassed in preference of SystemV init script.

[Jim Howell]

Trusty 14.04 LTS x86_64 Server

The upstart script invokes php5-fpm with --nodaemonize.

This causes several options from the config file to be ignored, including log file locations, pid file, and others. It also means that logging is done to /var/log/upstart/ and is no longer configurable.

Despite the advantages Upstart brings, these problems may cause some (like me) to choose to abandon Upstart for this particular package. Unfortunately, deleting the Upstart script does not have the intended effect of falling back to the /etc/init.d version by the same name.

Due to the following snippet from /etc/init.d/php5-fpm,

# Don't run if we are running upstart
if init_is_upstart; then
    exit 1
fi

it is impossible to successfully run the init script. The init script is permanently and fundamentally DISABLED by this snippet.

A notice or warning output would be more appropriate; or perhaps some additional value set from /etc/default/php5-fpm that would override this behavior. As things stand, I cannot use the init script without making an incompatible edit, which I would then have to fight to maintain against updates for the next few years.

Backwards-compatibility, please. This is the server version, after all!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jeff Waugh (jdub)]

This is quite a serious regression because it badly impacts integration with other systems that depend on sysvinit compatibility.

My use case: AWS::CloudFormation::Init (cfn-init) understands sysvinit services, but not upstream services. On Trusty, I can't restart php5-fpm with the init script due to this bug, therefore cfn-init won't restart it in response to file changes.

[Jeff Waugh (jdub)]

Bug is specific to php5-fpm.

[Ondřej Surý (ondrej)]

> This causes several options from the config file to be ignored

Well, I see only "error_log" being ignore in this case and not "several options".

You should really fill this bug with upstream (in PHP bug tracker), since it's wrong behaviour on FPM side to ignore configuration settings.

[Jeff Waugh (jdub)]

Looks like we've conflated two problems here -- ignoring options and the init script not working. Would it be inappropriate for me to rename this to focus on the init script issue?

[Jim Howell (jimbocoder)]

That sounds reasonable from my end.

[Ondřej Surý (ondrej)]

Nope, the init script is correct.

[Ondřej Surý (ondrej)]

I could probably prepare a patch, so --nodaemonize doesn't break logging, since this will break with Debian systemd as well. Whether it will be accepted by Ubuntu into trusty is up to Ubuntu maintainer.

[Jeff Waugh (jdub)]

The init script bails out if the system is using upstart, so anything that expects sysvinit compatibility won't work.

# Don't run if we are running upstart
if init_is_upstart; then
    exit 1
fi

[David Andruczyk (david-andruczyk)]

This completely breaks SYSLOG logging of PHP-fpm setups. Not daemoninzing the process results in php-fpm ignoring the error_log option and screws things royally in a multi-server setup where centralized logging is used with syslog...

Please revert this bad design.

[David Andruczyk (david-andruczyk)]

I developed a workaround based upon: http://serverfault.com/questions/114052/logging-a-daemons-output-with-upstart based upon the Last (Feb 12th) solution..

changed bits of /etc/init/php5-fpm.conf
script
  exec bash << EOT
  exec 1> >(logger -t syslog_tag_for_php) 2>&1
  exec /usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
EOT
end script

ps auxfw output
root 5961 0.0 1.6 924120 67144 ? Ss 13:41 0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
root 5963 0.0 0.0 9720 580 ? S 13:41 0:00 \_ bash
root 5964 0.0 0.0 4336 632 ? S 13:41 0:00 | \_ logger -t syslog_tag_for_php
www_pool 5969 0.0 0.3 923688 12308 ? S 13:41 0:00 \_ php-fpm: pool www_as_www_pool
. . .

A slightly better solution would have the "syslog_tag_for_php" as a variable sourced from /etc/default/php5-fpm so the init script is more generic.

This results in all php5-fpm master process logging going to syslog and easily filtered into an appropriate logfile by the tag, which is what was possible on 12.04 without this mucking around.

The ultimate issue is php5-fpm ignoring some configuration variables when run with the "--nodaemonize" option, and that needs addressing upstream.

[Pascal Brouwers (p-brouwers)]

The workaround let's me use config variables other than the default. Thank you David.
Any work on a patch?

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Since we use systemd in Ubuntu now (since 15.04), this bug no longer applies to the development release so I'm marking it Fix Released.

For upstart-using stable releases that are still supported, I don't think it's inappropriate to change the upstart script to not use --nodaemonize in an update automatically recommended to users as that will change behavior and thus clearly has the potential to regress users.

In terms of changing to the init.d script, you are welcome to do this by modifying or deleting the upstart and init.d scripts as appropriate as a workaround. They are in /etc and so packaging will attempt to preserve your changes by Debian policy. Given that you have to deleted the upstart job, it seems reasonable to me that you also have to manually edit the init.d script to enable it even if upstart is running.

But in any case, we can't fix this in Trusty for all users due to the regression risk, a workaround is available and the bug no longer applies with systemd in the development release for the future. Since there is no longer any work to do on this bug, Fix Released is appropriate.