PHP image cannot write PID file

[bizmate]

Hi folks,

I have tried using

FROM phpdockerio/php72-fpm:latest
WORKDIR "/application"

# Install selected extensions and other stuff
RUN apt-get update \
    && apt-get -y --no-install-recommends install  php7.2-mysql \
    && apt-get clean; rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

With a compose

php:
    build:
      context: docker/php7
    volumes:
      - ./shopify:/var/www/html
      - ./docker/php.ini:/etc/php/7.2/fpm/conf.d/php.ini
    user: $UID
    working_dir: /var/www/html
    depends_on:
      - mysql

And it is not able to write working files. The workaround is obvious but I think the base image should account for permissions on the PID file

php_1       | [21-Mar-2018 03:45:14] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
php_1       | [21-Mar-2018 03:45:14] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
php_1       | [21-Mar-2018 03:45:14] ERROR: Unable to create the PID file (/run/php-fpm.pid).: Permission denied (13)
php_1       | [21-Mar-2018 03:45:14] ERROR: FPM initialization failed

[luispabon]

In your case, the problems are caused by the user: $UID entry on your docker-compose - you're trying to execute php-fpm as your own user id within the container and /run belongs to root. Making that folder globally writable (which you would need if you want to write into it using an arbitrary user id) is not recommended.

[bizmate]

On the contrary, the fix is create the folder and have the fpm user own it instead of avoiding the problem. Using the UID from the host is necessary to avoid having working files written by root or FPM on the host with host volumes and having all sorts of annoyances in dealing with these working files on the host. The problem is not present in other images or set ups as it is quite standard that the process should be runnable by a UID as overridden with docker-compose or docker run so that in local dev setups permissions are correct on both host and container for the shared files.

[luispabon]

How exactly would you create the /run folder in advance if you don't know the user id of whoever's running it? Would need to be created dynamically on php-fpm up, and only root can have write access at /. Bear in mind also that this needs to run in the mac which use a very different range of user IDs (eg they don't start at 1000for login users like it does on most linux distros).

What files are you creating that you need available back in your host? Caches and whatnot should probably go into /dev/shm.

[luispabon]

I'm always happy to receive PR to fix issues btw, if you have clear in your mind how to tackle this particular problem don't be shy :+1:

[bizmate]

@luispabon i will indeed try to check if I can work out a fix for this, ie you are right assigning the user id in Mac might cause problems but a clear use case (for me) that makes a difference is the use of composer through docker. I tend to use this approach these days and mount the folders, the files are written by the container user if you dont use the host UID and using composer on the host is not an option (in my way of doing things) because of a CI environment I want the minimal set of tooling on the host and instead leverage containerisation everywhere. Right now I am using the dirty workaround mkdir -p /run && chmod 777 /run but if I have time I will take a look at why I have not seen this error on other original php images and maybe come up with a PR. Thanks for your time so far

Example of a composer install

  composer:
    image: composer
    user: $UID
    depends_on:
      - php
    volumes:
      - $PWD:/app
    command: composer install --ignore-platform-reqs