This also happens in Mac OS 14.1 Sonoma:

rosetta error: futex(FUTEX_LOCK_PI_PRIVATE) failure: 35
 Trace/breakpoint trap

FROM php:8.1-cli
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]
CMD ["bash"]

Docker info:

Client:
 Version:    24.0.6
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.2-desktop.5
    Path:     /Users/nikbr/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.22.0-desktop.2
    Path:     /Users/nikbr/.docker/cli-plugins/docker-compose
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.0
    Path:     /Users/nikbr/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.20
    Path:     /Users/nikbr/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v0.1.0-beta.8
    Path:     /Users/nikbr/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/nikbr/.docker/cli-plugins/docker-sbom
  scan: Docker Scan (Docker Inc.)
    Version:  v0.26.0
    Path:     /Users/nikbr/.docker/cli-plugins/docker-scan
  scout: Docker Scout (Docker Inc.)
    Version:  v1.0.7
    Path:     /Users/nikbr/.docker/cli-plugins/docker-scout

Server:
 Containers: 26
  Running: 11
  Paused: 0
  Stopped: 15
 Images: 59
 Server Version: 24.0.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
 runc version: v1.1.8-0-g82f18fe
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.4.16-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 23.45GiB
 Name: docker-desktop
 ID: 9df56d26-7dbe-46c2-a946-427b0766499b
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Diagnostics ID

B99BCF91-9CAF-4D12-AE8B-A4858EC43329/20231026100519

Well that's today's best laugh!

It looks like Orbstack was able to fix this, maybe it is time to migrate?

Hi @NiklasBr, do you have a sample command that triggers the issue?
We are shipping fixed for Rosetta in 4.26.0 and I would like to check if this issue is fixed.

@dgageot

Create a Dockerfile using the example I posted above, then run any Composer command docker compose run --rm your-docker-project-name composer

@dgageot related and another example of the same thing I think: #6887 (comment)

@NiklasBr sorry, I don't know compose enough to trigger an issue. Do I need a sample composer.json file?

I've tried a compose install with this composer.json and couldn't reproduce an issue.

{
  "name": "yourname/hello-world",
  "description": "A hello world package",
  "keywords": [
    "hello world"
  ],
  "license": "GPL-3.0-or-later",
  "authors": [
    {
      "name": "Joseph Edmonds",
      "email": "info@ltscommerce.dev"
    }
  ],
  "require": {
    "php": ">= 8.0.1"
  },
  "autoload": {
    "psr-4": {
      "YourName\\HelloWorld\\": "src/"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "YourName\\HelloWorld\\Test\\": "tests/"
    }
  },
  "require-dev": {
    "roave/security-advisories": "dev-master",
    "phpunit/phpunit": "^9.5"
  },
  "minimum-stability": "stable",
  "config": {
    "bin-dir": "bin"
  },
  "bin": [
    "bin/hello"
  ]
}

I probably need something more complex.

Looks like maybe you are on an amd64 architecture and not arm64?

You don't even need to install anything just like me and the other people are saying,: You can run composer without any arguments whatsoever and reproduce the issue 100% of the time.

You can make it less complex.

Thanks @NiklasBr for the details. Although that’s not my experience. I can’t make it fail no matter what I do

Again, make sure the docker image is not an ARM architecture.

Then, make sure you are using Rosetta.

It's really as simple as that. I can't wrap my head around why you can't reproduce it. Many of us are able to do it with 100% rate, and it has followed along with many updates of both Docker Desktop and the Mac OS operating system.

Again, make sure the docker image is not an ARM architecture.

Then, make sure you are using Rosetta.

Yes, all of that I have...

Some of the Rosetta issues were fixed in Sonoma 14.1. Which version of macOS do you have?

Sonoma 14.1 as mentioned a few weeks ago on an M1 Max CPU.

My experience is that Rosetta still works exactly as problematic as it did with Mac OS 13.6.

I'm on Sonoma 14.1, with a Mac M1 Pro and a Mac M2 Pro. Can't reproduce on any of the last five Docker Desktop versions.

I've tried things more complicated than that but can you tell me if this simple command fails for you?

docker run --rm -it --platform=linux/amd64 composer/composer install

You need to use and AMD64 image and use Rosetta.....

You need to use and AMD64 image and use Rosetta.....

Yeah. That's what I've been doing.
Do you confirm that docker run --rm -it --platform=linux/amd64 composer/composer install triggers the issue for you, or not?

I'm sorry to insist but if nobody can give me a command that reproduces the issue, I'll be forced to close this ticket.

Do you confirm that docker run --rm -it --platform=linux/amd64 composer/composer install triggers the issue for you, or not?

Your command and setup obviously does not trigger it.

I repeat, the way to trigger it, as mentioned earlier, is to enable Rosetta in Docker Desktop settings, then run an AMD64 image using the following command on an ARM Mac: docker compose run --rm your-docker-project-name composer. Why do you insist on using a different command which does not trigger the error?

@dgageot I am facing the same issue on Mac OS Sonoma 14.1 running on Mac pro m2 chip.
Here is sample step by step to replicate

1. Create a docker file as below

# Use Amazon Linux 2023 as the base image
FROM --platform=linux/amd64 amazonlinux:2023

# Install PHP 8.1
RUN dnf update \
    && dnf search php8.1 \
    && dnf install php8.1 -y

# Set the entry point to PHP CLI
ENTRYPOINT ["bash"]

2. Build the image using the dockerfile i.e
   docker build --tag "php-8.1-cli" /location/of/Dockerfile

3. Run the container using the image created above
   docker run -it --rm php-8.1-cli

4. Inside the container try run php commands like:
   php -v

Result:
You should see the error below

My docker info:

Client:
Version: 24.0.6
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2-desktop.5
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.23.0-desktop.1
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-compose
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.20
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v0.1.0-beta.9
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-sbom
scan: Docker Scan (Docker Inc.)
Version: v0.26.0
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-scan
scout: Docker Scout (Docker Inc.)
Version: v1.0.9
Path: /Users/jumakiwaka/.docker/cli-plugins/docker-scout

Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 55
Server Version: 24.0.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
runc version: v1.1.8-0-g82f18fe
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.4.16-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 8
Total Memory: 7.758GiB
Name: linuxkit-2a1f1b2d0463
ID: 055c4bd8-48dc-4ded-a9ba-7cecc8e48a19
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Docker Desktop Version: 4.25.1

Please let me know if you have any questions.

Thanks a lot @jumakiwaka. Using your precise instructions, I was able to reproduce.

One way to reproduce it even faster is to run:

$ docker run --rm -it --platform=linux/amd64 php bash

and then, simply:

# php -v
PHP 8.1.25 (cli) (built: Oct 24 2023 21:51:16) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.1.25, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.25, Copyright (c), by Zend Technologies
rosetta error: futex(FUTEX_LOCK_PI_PRIVATE) failure: 35
 Trace/breakpoint trap

I tried to combine those two commands in one but this doesn't fail:

$ docker run --rm -it --platform=linux/amd64 php bash -c 'php -v'

EDIT:

It doesn't fail with the stock php image. Probably only with a version that has php-ocache installed:

cat << EOF | docker -c dev-mode build -f- --platform=linux/amd64 -t php /var/empty
FROM centos:7
RUN yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm
RUN yum-config-manager --enable remi-php81
RUN yum update -y
RUN yum install -y php
RUN yum install -y php-opcache
EOF

Here's a simpler way to reproduce:

Build a php image with opcache enabled:

cat << EOF | docker build -f- --platform=linux/amd64 -t php-opcache /var/empty
FROM php:8.1.25
RUN docker-php-ext-install opcache
RUN echo "[opcache]\nopcache.enable_cli=1" > /usr/local/etc/php/conf.d/opcache.ini
EOF

Run the image:

docker run --rm -it --platform=linux/amd64 php-opcache bash

Type the faulty command:

php -v

This fails with php 8.1.25.
This doesn't fail with any 8.2.X version of php.

@jumakiwaka could you try to add this to /usr/local/etc/php/conf.d/opcache.ini?

[opcache]
opcache.preferred_memory_model=shm

Looks like a fix / improvement was made in Docker Desktop, which will ship with the next release

Looks like a fix / improvement was made in Docker Desktop, which will ship with the next release

Do we know which version includes the fix? I just upgraded to Docker Desktop 4.26.0 (130397) and the problem still happens for me.

Dockerfile

FROM --platform=linux/amd64 grafana/k6 

USER root
RUN apk update

Notes

• My problem occurs at build time, not run time.
• grafana/k6 is a load testing utility implemented in Go.
• I use apk to install other needed packages, but just running apk update is enough to repro.

Build

$ docker build .
[+] Building 1.0s (5/5) FINISHED                                                                                                                                                                                                   docker:desktop-linux
 => [internal] load build definition from Dockerfile                                                                                                                                                                                               0.0s
 => => transferring dockerfile: 1.34kB                                                                                                                                                                                                             0.0s
 => [internal] load .dockerignore                                                                                                                                                                                                                  0.0s
 => => transferring context: 2B                                                                                                                                                                                                                    0.0s
 => [internal] load metadata for docker.io/grafana/k6:latest                                                                                                                                                                                       0.3s
 => CACHED [1/2] FROM docker.io/grafana/k6@sha256:c92b70d9015e6c58f58fb10ddf382cfe2fb823a48bb0a1cc3bca31f4a87b65fc                                                                                                                                 0.0s
 => ERROR [2/2] RUN apk update                                                                                                                                                                                                                     0.7s
------
 > [2/2] RUN apk update:
0.100 fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
0.388 fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
0.621 v3.18.5-17-g1e9547d0183 [https://dl-cdn.alpinelinux.org/alpine/v3.18/main]
0.621 v3.18.5-18-g8eb8adbd2d7 [https://dl-cdn.alpinelinux.org/alpine/v3.18/community]
0.621 OK: 20076 distinct packages available
0.647 rosetta error: futex(FUTEX_LOCK_PI_PRIVATE) failure: 35
0.647
------
Dockerfile:9
--------------------
   7 |     # RUN mkdir -p /app
   8 |
   9 | >>> RUN apk update
  10 |
  11 |     # RUN apk update && \
--------------------
ERROR: failed to solve: process "/bin/sh -c apk update" did not complete successfully: exit code: 133

System

• macOS Ventura 13.6.2 (22G320)
• Apple M1
• Docker Desktop 4.26.0 (130397)

FROM --platform=linux/amd64 grafana/k6 

USER root
RUN apk update

Well I found a workaround. This works for my case:

FROM --platform=linux/amd64 grafana/k6 

USER root
RUN apk upgrade -U

(My real use case calls apk update followed by apk upgrade, so the above does the same.)

This all seems very non-deterministic to me though. I'll be interested to hear where it lands.

Hi @matsaleh13, a similar issue was fixed with php in Docker Desktop 4.26.0.
The futex issue you are seeing is fixed on Rosetta itself, in Sonoma.
I'm on 14.1.1 and can't reproduce your issue

The futex issue you are seeing is fixed on Rosetta itself, in Sonoma.

Ohh... do you know whether Apple will backport the fix to Ventura? I guess they're not known too well for that kind of thing, right?

Well, thanks for clarifying that, and thanks for the prompt response!

Ohh... do you know whether Apple will backport the fix to Ventura? I guess they're not known too well for that kind of thing, right?

Indeed. I don't think they will

I'm going to close this issue. Feel free to reopen if you manage to reproduce on a recent macOS.

@dgageot

This just occurred to me on Mac OS X Sonoma 14.3 when installing PHP FPM 8.1 from the ppa:ondrej/php repo on ubuntu:latest.

Steps to recreate:

Create the following Dockerfile:

FROM ubuntu:latest

RUN set -eu; \
    #
    apt-get update; \
    #
    # Configure ondrej PPA
    apt-get install -y software-properties-common; \
    add-apt-repository ppa:ondrej/php; \
    apt-get update; \
    #
    # Install PHP
    apt-get install -y --no-install-recommends php8.1-fpm; \
    #
    # Make sure everything works
    php-fpm8.1 -v

Run the following command:

docker buildx build --platform linux/amd64 .

System info:

Docker settings:

Thanks a lot @Chekote, I'm giving it a try right now

@Chekote a fix is one the way. I might be included in Docker Desktop 4.27.1 hot fix.

@dgageot awesome! Thanks for the amazingly fast resolution ❤️

What happened is that in 4.26, we removed the support for Huge Tables that caused issues with php. This was a bit too brutal of a fix but php users were happy.

In 4.27, we put back Huge Tables and added a targeted fix for php. We forgot to also target other flavours of php such as php-cgi* or php-fdm*.

Hi @Chekote! Docker Desktop 4.27.1 is out. Could you tell me if it solves your issue?

Just updated to Docker Desktop 4.27.1 (136059) and am now seeing the following:

+ echo 'Starting php-fpm'
+ /opt/remi/php##/root/usr/sbin/php-fpm
Starting php-fpm
[01-Feb-2024 18:07:27] ERROR: no data have been read from pipe
rosetta error: futex(FUTEX_LOCK_PI_PRIVATE) failure: 35
894 Trace/breakpoint trap   /opt/remi/php##/root/usr/sbin/php-fpm

@dgageot 4.27.1 is a security release for the runc and buildkit advisories; other patches/fixes will now be in 4.27.2 (next week)

@dgageot 4.27.1 is a security release for the runc and buildkit advisories; other patches/fixes will now be in 4.27.2 (next week)

Rolling back to 4.26.1 appears to resolve the issue I mentioned above for me, for now. Btw, I noticed the date on the release notes for 4.27.1 is accidentally showing 2023-02-01 instead of 2024-02-01, just a heads up :)

I noticed the date on the release notes for 4.27.1 is accidentally showing 2023-02-01 instead of 2024-02-01, just a heads up :)

Good catch! Looks like someone fixed it ❤️ docker/docs#19289

Also apologies for the confusion for the 4.27.1 release not having these patches; these patches (fixes) were merged already, but the embargoed security took priority, and it's generally good practice not to combine regular fixes with a security release, to prevent possible regressions (which may prevent users from being able to use the security fixes).

Hi @Chekote! Docker Desktop 4.27.1 is out. Could you tell me if it solves your issue?

Unfortunately it doesn't. I still see the problem

Hi @Chekote, @eolivelli and @Chekote!
Docker Desktop 4.27.2 is out. Could you tell me if it solves your issue?

I still have PHP-FPM issues in 4.27.2: #7182

Not sure if it is actually Rosetta… But the effect is that 4.27.x is still not stable enough on ARM Mac:s to get an environment up and running :(

Temporary fix (worked for me on M1 mac):

• Turn off Rosetta
• Build image
• Turn on Rosetta

Temporary fix (worked for me on M1 mac):

• Turn off Rosetta
• Build image
• Turn on Rosetta

Building with EXPERIMENTAL_DOCKER_DESKTOP_FORCE_QEMU=1 docker build ... should also work.

@dgageot 4.27.2 resolved the problem I reported earlier. I am performing some more builds just to be sure. I'll keep you posted.

@dgageot I was able to build many PHP images for many projects, both CLI and FPM, for PHP versions 8.1.27, 8.2.15, and 8.3.2 without any problems.