Closed rburgst closed 2 months ago
This is the relevant section of my dockerfile:
# taken from https://frankenphp.dev/docs/docker/
FROM dunglas/frankenphp
LABEL maintainer="Rainer Burgstaller"
ARG USER=www-data
ARG WWWGROUP=www-data
RUN \
# Use "adduser -D ${USER}" for alpine based distros
useradd -D ${USER}; \
# Add additional capability to bind to port 80 and 443
setcap CAP_NET_BIND_SERVICE=+eip /usr/local/bin/frankenphp; \
# Give write access to /data/caddy and /config/caddy
chown -R ${USER}:${USER} /data/caddy && chown -R ${USER}:${USER} /config/caddy;
WORKDIR /app
ENV DEBIAN_FRONTEND noninteractive
ENV TZ=UTC
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apt-get update && apt-get install -y gnupg
RUN install-php-extensions gd pdo_mysql zip intl
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
RUN chown -R $USER:$WWWGROUP /app
EXPOSE 80
RUN mkdir /.composer && \
chmod -R ugo+rw /.composer && \
chown -R $USER /.composer
# Switch to use a non-root user from here on
USER ${USER}
# Add application
WORKDIR /app
COPY --chown=${USER}:$WWWGROUP backend /app
RUN cd /app && \
mkdir -p /app/storage/logs
RUN composer install --no-interaction --no-dev --prefer-dist --optimize-autoloader
This is the relevant section of the docker-compose.yml
services:
fp:
image: me/image
ports:
# laravel
- '8002:443'
environment:
PORT: 81 # eventually I want to control the port also via ENV as heroku requires this
user: '33:33'
networks:
- app-network
Yes, I know running it with an external provided uid is uncommon, but I want to deploy on heroku and they run their images with arbitrary uids, so this is a first step to getting there.
What are you passing to set_time_limit()
? Is it a valid argument according to https://www.php.net/manual/en/function.set-time-limit.php?
I'm just trying to rule out configuration errors, as this could be an actual issue in php-src that may need to be fixed.
edit to add: we are using a multi-threaded version of timers that isn't used in fpm/apache for setting max execution time. That's why I'm curious what you are passing there. It might be an edge case, or an untested code path, or something, so being able to reproduce it, so we can create a test upstream in PHP, and a patch PR would be super helpful.
My bet is that using timer_create()
require some Linux capacities that are disabled in this rootless+Docker context.
Possibly CAP_WAKE_ALARM
but we aren't using alarms, or an old kernel that doesn't have CLOCK_BOOTTIME
available. It'd be worth trying to run as root, @rburgst, to see if that fixes it. If so, then it is a capability issue, if not, can you share the kernel version of your docker host: uname -r
$ uname -r
6.5.0-15-generic
when I run the container without the user: 33:33
directive, then the problem stays the same.
What are you passing to set_time_limit()? Is it a valid argument according to https://www.php.net/manual/en/function.set-time-limit.php?
I am not passing anything specific in there (as this is statatmic code), but when I debug, I see that -1
is being passed in.
When I run this locally on my mac this also is the same value and it doesnt cause a problem there (which doesnt say much). However, this code also works fine on a apache-fpm container as root.
@withinboredom I tried adding
setcap CAP_WAKE_ALARM=+eip /usr/local/bin/frankenphp; \
to the dockerfile but that caused the container to stop immediately (note that I dont know how to properly use setcap
, i just did copy paste from the existing setcap
call).
-1 is in fact an invalid number to pass to timer_create
and is also an invalid value to pass to set_time_limit()
, which it appears to silently fail on in non-zts PHP (or is perhaps treated as 0
).
Either way, -1
is undefined behavior, so I'm not sure what the proper fix is. I'll go open an issue on the statatmic repo for now, as a fix in PHP is likely to take much longer.
Looks like it is already merged: https://github.com/statamic/cms/pull/9297
Are your dependencies up to date?
Todo:
https://externals.io/message/123108 to discuss proper behavior
Closing in favor of externals.io/message/123108 and https://github.com/php/php-src/pull/13942 as it's a PHP bug, not related to FrankenPHP.
I am using
"name": "statamic/cms",
"version": "v4.53.2",
which is approx 1 month old, the referenced fix was merged in January, so I would have thought that this should have been fixed already. At any rate I did actually get it to work with a naked sample installation of statamic: https://github.com/rburgst/frankenphp-statamic
So now I only need to figure out what else is wrong in my actual application :)
What happened?
I am trying to serve a laravel statamic application via the non-root version of the docker container When accessing the admin panel I get the following error
Build Type
Docker (Debian Bookworm)
Worker Mode
No
Operating System
GNU/Linux
CPU Architecture
Apple Silicon
PHP configuration