Page MenuHomeDevCentral

Document what to do if php-fpm lost pid files
Closed, ResolvedPublic

Description

On a FreeBSD server, this can happens after a PHP package:

$ /usr/local/etc/rc.d/php-fpm start
Performing sanity check on php-fpm configuration:
[17-Feb-2018 14:46:07] NOTICE: configuration file /usr/local/etc/php-fpm.conf test is successful

Starting php_fpm.
$ /usr/local/etc/rc.d/php-fpm status
php_fpm is not running.

We edit the RC service to use different paths than the default one.

We should document the roles/webserver-legacy/php-sites/php-fpm should be run again afterwards.

Alternatively, we can also deploy to another service name or reach the package maintainer with our multi-instance solution.

Event Timeline

dereckson renamed this task from php-fpm lost pid files to Document what to do if php-fpm lost pid files.Feb 20 2018, 08:13
dereckson updated the task description. (Show Details)
dereckson added a project: documentation.
dereckson triaged this task as Normal priority.EditedOct 12 2024, 09:36

The problem is somewhat fixed by two things:

  1. we've introduced in 0ba9786b a restart-php-fpm taking care to fetch from Salt repository the up-to-date version
  2. upstream FreeBSD package has just changed the name into php_fpm

A new problem arise: we'll have after a PHP update two services, ours under the old name, the package one under the new name.

Plan is to update restart-php-fpm accordingly, delete php_fpm to avoid confusion and that's it.

dereckson claimed this task.