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

[jfastnacht]

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:

1. 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"

2. Run ddev with ddev start
3. Wait until the LDAP module is installed
4. See error
5. ddev ssh into machine and check php -m, the module is installed
6. 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
```yaml
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!

[rfay]

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]

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).

[jfastnacht]

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)

[rfay]

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 :)

[sbaghdadi]

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 :).

[rfay]

Please take a look at https://github.com/drud/ddev/pull/1121 and see what you think about it, or if you have any suggestions.

I do think it might make sense to eventually just add a list of extra requested modules in config.yaml.