Ddev: /usr/sbin/policy-rc.d prevents service restart after PHP module installation (specifically php-ldap)

Created on 18 Sep 2018 · 6Comments · Source: drud/ddev

Describe the bug
When installing php-ldap with post-start hooks (as recommended) the restart of the services to activate the LDAP module fails due to the /usr/sbin/policy-rc.d (https://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt) which is set to exit 101 by default.

Setting up php7.1-ldap (7.1.20-1+0~20180910100430.3+jessie~1.gbp17c613) ...

Creating config file /etc/php/7.1/mods-available/ldap.ini with new version
Processing triggers for php7.1-fpm (7.1.20-1+0~20180910100430.3+jessie~1.gbp17c613) ...
/usr/sbin/invoke-rc.d: 1: /usr/sbin/invoke-rc.d: /sbin/runlevel: not found
invoke-rc.d: policy-rc.d denied execution of restart.

To Reproduce
Steps to reproduce the behavior:

Add post-start hook to install php-ldap into config.yaml

hooks:
  post-start:
  - exec: "apt-get update"
  - exec: "apt-get -y install php7.1-ldap"

Run ddev with ddev start
Wait until the LDAP module is installed
See error
ddev ssh into machine and check php -m, the module is installed
Check phpinfo() on webserver, the module is not activated

You can ddev stop and ddev start again, the module should be active after the restart.

Expected behavior
The service should restart properly and the PHP module should work without restarting the whole project.

Since I assume that this is not only a problem of the LDAP module, it might be good to think about implementing a way to properly configure PHP modules over the config.yaml and to unify the installation process of PHP modules.

Version and configuration information (please complete the following information):

Host computer OS and Version: Windows 8.1
Docker version information (use docker version) and insert it here.

Client:
 Version:       18.03.0-ce
 API version:   1.37
 Go version:    go1.9.4
 Git commit:    0520e24302
 Built: Fri Mar 23 08:31:36 2018
 OS/Arch:       windows/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.06.1-ce
  API version:  1.38 (minimum version 1.12)
  Go version:   go1.10.3
  Git commit:   e68fc7a
  Built:        Tue Aug 21 17:28:38 2018
  OS/Arch:      linux/amd64
  Experimental: false

ddev version information (use ddev version)

web     drud/ddev-webserver:v1.1.0
db      drud/ddev-dbserver:v1.1.0
dba     drud/phpmyadmin:v1.1.0
router  drud/ddev-router:v1.1.0
commit  v1.1.1
domain  ddev.local
cli     v1.1.1

config.yaml contents for the misbehaving project

APIVersion: v1.1.1
name: projectnamechanged
type: php
docroot: web/
php_version: "7.1"
router_http_port: "9080"
router_https_port: "9443"
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
provider: default
hooks:
  post-start:
  - exec: "apt-get update"
  - exec: "apt-get -y install php7.1-ldap"
  - exec: "composer install -d /var/www/html/"

Do you have any custom configuration (nginx, php, mysql) in the .ddev folder? If so, have you tried without them?

A custom nginx-site.conf for Symfony. Would post only if necessary.

Additional context
~~Add any other context about the problem here. Thanks!~~

Source

jfastnacht

👍2

All 6 comments

The web container does not use debian's init system, it uses supervisord, so restarts of that type can never work. However, you might consider just trying a killall -HUP php-fpm after the install.

Perhaps your second line can be bash -c "apt-get install -y php7.1-ldap || true" and then another line tokillall -HUP php-fpm`

rfay on 18 Sep 2018

👍1

Oh, I just tried this; that's not an error and doesn't end with non-true response code, it just can't restart fpm because we don't use regular service stuff, we use supervisord, so if needed, do the killall -HUP php-fpm or if that's not enough you can do a killall -HUP 1 (to reload supervisord from scratch).

rfay on 18 Sep 2018

👍1

Thank you for the fast reply, the killall -HUP php-fpm fixed it, even if it looks odd to me.

Since I haven't found any related issue, I wonder if I am the first one to stumble over that (I doubt it). Could you consider adding that to the official documentation on https://ddev.readthedocs.io/en/latest/users/extending-commands/?

Have you considered unifying the PHP module installation process over the config.yaml? (Maybe a topic for a separate ticket)

jfastnacht on 18 Sep 2018

It's a good idea; Adding a PHP module is slightly different from lots of other things as you point out.

the HUP signal (signal 1) is the old time Linux way to get a daemon to reload. "kill" is just a utility to send a signal, which by default sends signal 15 (TERM), but can send any other signal. killall just kills by process name. SO that's the story on that :)

rfay on 19 Sep 2018

Glad to hear this problem could be solved. I give my +1 for adding this to the docs. I also would like to see the feature, adding PHP-modules with some kind of configuration outsides the containers. The preinstalled modules fulfills a lot of requirements but not all. Especially the ldap module is often needed. So herefore also my +1 :).