`setup:di:compile` segfaults with OPcache enabled & Varnish frontend intermittently inaccessible after project start

[usamaTudock]

Environment

Component	Version
riptide-all	0.10.0
riptide-lib	0.10.1
riptide-cli	0.10.1
riptide-engine-docker	0.10.0
riptide-proxy	0.10.0
riptide-plugin-php-xdebug	0.10.1
PHP Image	docker.pkgs.tudock-stage.de/magento2/apache-php:8.2
Magento App	/app/magento2/ce/2.4-opensearch
Varnish Image	varnish:6
OS	Linux 6.14.0

---

Bug 1: magento setup:di:compile silently segfaults when OPcache is enabled

Description

Running riptide cmd magento setup:di:compile in barthel exits immediately with no PHP error output — only Segmentation fault (core dumped). No stack trace, no log entry.

The magento command is defined with in_service_with_role: php, so it runs inside the same container where PHP-FPM is already running with OPcache active. When di:compile generates a large number of classes, the shared file-based OPcache causes memory mapping conflicts that result in a segfault.

Workaround

Create a riptide.local.yml that mounts a custom ini file to disable OPcache:

# riptide.local.yml
project:
  app:
    services:
      php:
        additional_volumes:
          memory_ini:
            container: /etc/php.d/zzz-memory.ini
            host: ./php_memory.ini

# php_memory.ini
memory_limit=-1
opcache.enable=0
opcache.enable_cli=0

The zzz- prefix ensures it loads last and overrides any earlier OPcache settings. After this, setup:di:compile completes successfully.

Expected behavior

setup:di:compile should work out of the box.

---

Bug 2: Varnish frontend intermittently inaccessible after riptide start

Description

After riptide start, the frontend served through Varnish is frequently inaccessible — times out or returns a connection error. This is not a transient startup delay; it persists across multiple retries.

The Varnish pre_start only checks network reachability via ping:

varnish:
  image: varnish:6
  port: 80
  roles:
    - main
    - main          # duplicate
    - magento_front
  pre_start:
    - until ping -c5 php &>/dev/null; do :; done

Ping confirms the PHP container is up, but not that Nginx/PHP-FPM inside it is ready to serve HTTP. Varnish starts, gets connection refused from its backend, and caches that broken state.

Steps to reproduce

1. riptide start
2. Open https://barthel.riptide.<username>.local/
3. Page is inaccessible / times out
4. Retrying does not help
5. Only deleting ~/.cache/riptide/barthel/ and restarting resolves it — until the next cold start

Expected behavior

The frontend should be reliably accessible after riptide start completes.

Summary

Issue	Cause	Severity	Workaround
di:compile segfault	OPcache enabled + shared file cache volume	Blocking	Disable OPcache via riptide.local.yml
Varnish FE inaccessible	pre_start ping ≠ HTTP readiness + stale cache	High	Delete ~/.cache/riptide/barthel/ and restart