Apple segfaults when php-fpm scripts invoke gettext

[Saeven]

brew gist-logs <formula> link OR brew config AND brew doctor output

https://gist.github.com/Saeven/ff8bc2e732a23622b1b5e784b83269c1

Verification

• My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

PHP installs without issue, however, after installation any script that invokes gettext causes a crash. I'm unable to get a core for some reason, but I've isolated the issue to gettext.

Can confirm that it works on my old Intel Mac, but not on the M2 (mine) or that of a colleague (same CPU).

Create a script that contains:

<?php

echo gettext("hello");

Try to access the script via php-fpm and you get a bad gateway with a segfault in logs. Curiously, accessing via CLI produces the expected output.

What happened (include all command output)?

saeven@SaevenStudio ~ % sudo /opt/homebrew/opt/php/sbin/php-fpm --nodaemonize
Password:
[24-Jul-2023 15:53:20] NOTICE: fpm is running, pid 19583
[24-Jul-2023 15:53:20] NOTICE: ready to handle connections
[24-Jul-2023 15:53:30] WARNING: [pool www] child 19584 exited on signal 11 (SIGSEGV) after 9.763474 seconds from start
[24-Jul-2023 15:53:30] NOTICE: [pool www] child 19587 started

What did you expect to happen?

No segfaults on access.

Step-by-step reproduction instructions (by running brew commands)

brew install php
brew install nginx

[SMillerDev]

@carlocab could this be related to your recent changes?

[carlocab]

Maybe? Hard to say without a backtrace.

[carlocab]

@Saeven, could you try doing

git -C "$(brew --repository)" checkout 4.0.29
brew reinstall php $(brew deps php)
git -C "$(brew --repository)" checkout -

and see if that helps?

[jonquihote]

I'm having a similar issue as well, though not related to gettext. In my case, any query to the database using pgsql driver would return SIGABRT in php-fpm.log. Using other database driver proves to be fine.

That being said, using php built-in server, everything seems to be working as usual.

The code snippets by @carlocab seems to fix the issue. Thanks a heap @carlocab

[carlocab]

It's really more of a workaround rather than a fix. We should figure out what's going wrong and fix it properly, as that workaround is going to stop working at some point.

[jonquihote]

I agree as well. I would like to take a stab on finding the cause of this issue if I can get some guidance. It's my first time dealing with homebrew or package manager in general.

I saw that you mentioned a backtrace. How would one do a backtrace?

[Saeven]

Here to help if you need a backtrace; truth is I spent a few minutes trying to get one for myself but the darned thing won't dump.

saeven@SaevenStudio ~ % ulimit -c
unlimited

saeven@SaevenStudio ~ % sysctl -a | grep core
kern.corefile: /cores/core.%P
kern.coredump: 1
kern.sugid_coredump: 1
kern.sched_recommended_cores: 16777215
kern.drivercorefile: /cores/core.%P
machdep.cpu.cores_per_package: 24
machdep.cpu.core_count: 24
saeven@SaevenStudio ~ % 

And then in the config area:

grep -r "core" *    
php-fpm.conf:; Set max core size rlimit for the master process.
php-fpm.conf:rlimit_core = unlimited
php-fpm.d/www.conf:; core dump and ptrace the process for the pool user.
php-fpm.d/www.conf:; Set max core size rlimit.
php-fpm.d/www.conf:rlimit_core = unlimited

grep -r "dumpable" *
php-fpm.d/www.conf:; Set the process dumpable flag (PR_SET_DUMPABLE prctl) even if the process user
php-fpm.d/www.conf:process.dumpable = yes

saeven@SaevenStudio / % ls -l | grep core
drwxrwxr-t   2 root  wheel    64  5 May 21:05 cores

Anything I've missed?

[joshbyvelds]

I am having the same issue as Saeven. Tried to reinstall php using the suggestion here and it still fails with the same error logs.

`[25-Jul-2023 15:34:36] NOTICE: fpm is running, pid 88426

[25-Jul-2023 15:34:36] NOTICE: ready to handle connections

[25-Jul-2023 15:35:51] WARNING: [pool www] child 88428 exited on signal 6 (SIGABRT) after 74.611026 seconds from start

[25-Jul-2023 15:35:51] NOTICE: [pool www] child 89954 started

[25-Jul-2023 15:36:23] WARNING: [pool www] child 88429 exited on signal 9 (SIGKILL) after 106.788182 seconds from start

[25-Jul-2023 15:36:23] NOTICE: [pool www] child 90238 started

[25-Jul-2023 15:36:28] WARNING: [pool www] child 88431 exited on signal 6 (SIGABRT) after 111.407527 seconds from start

[25-Jul-2023 15:36:28] NOTICE: [pool www] child 90309 started

[25-Jul-2023 15:41:24] WARNING: [pool www] child 88430 exited on signal 6 (SIGABRT) after 408.270930 seconds from start

[25-Jul-2023 15:41:24] NOTICE: [pool www] child 92347 started`

[askdkc]

@Saeven @jonquihote @joshbyvelds

Related this #137909 (comment)

Could you add following code to your /opt/homebrew/Cellar/php/8.2.8/homebrew.mxcl.php.plist and restart your php-fpm and see if it works (or not) please?

• Before

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>

• After

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>EnvironmentVariables</key>
        <dict>
            <key>OBJC_DISABLE_INITIALIZE_FORK_SAFETY</key>
            <string>YES</string>
        </dict>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>

I'm using Laravel Valet and tested like this:

1. Make Valet Site and add index.php file

mkdir ~/Sites/testsite
vi ~/Sites/testsite/index.php

inside index.php file:

<?php

echo gettext("hello");

2. Access to testsite.test which will serve index.php above
   -> This will throw 502 Bad Gateway

3. Change /opt/homebrew/Cellar/php/8.2.8/homebrew.mxcl.php.plist to like above example and restart Laravel Valet (which restart php-fpm with new homebrew.mxcl.php.plist parameter)

4. Access to testsite.test, now it outputs 'hello' without any problem.

[SMillerDev]

None of the previous posts talks about valet or brew services though, so that won't fix their usecase

[askdkc]

None of the previous posts talks about valet or brew services though, so that won't fix their usecase

@SMillerDev Laravel Valet uses php-fpm behind the scene so if it works, it related with php environment setting. Let's test this to figure out what is the cause of the issue.

[Saeven]

@askdkc Editing the the startup task with those parameters, so far, does eliminate the segfault being experienced. No Laravel here (Laminas!) - but in an nginx+php-fpm stack it allows the script to run. 🎉

[askdkc]

@SMillerDev @Saeven

Laravel Valet is just a service wrapper which does manage nginx, php and dnsmasq services using homebrew services behind the scene to setup php environment. So it is actually all related with homebrew packages and services. (just php in this case).

So far we found out that running php-fpm via nginx and apache encounter segfault. And adding OBJC_DISABLE_INITIALIZE_FORK_SAFETY will fix it.

Why this happen?

Apple used to allow these process to run just logging warnings to the log. It was perfectly fine until Apple decided to kill it.

Did homebrew screw things up? No. Homebrew did nothing wrong.
Did php screw things up? No. php did nothing wrong.

How about Linux? Does it kill php fork process? No.

Does adding OBJC_DISABLE_INITIALIZE_FORK_SAFETY to env is dangerous? Yes and No. Because even without adding this env parameters, problem has always been there. It keeps logging the warnings but also working fine.

Did your php code ever kill your OS using php-fpm? Your entire system? No. (Well, if you screw up with your php code really bad, it might be?)

So it was like php-fpm was running with OBJC_DISABLE_INITIALIZE_FORK_SAFETY ON all the time.

Only Apple who decided to kill it.

Linux: "this is fine. Keep going."
Windows: "we don't have fork() process like Linux and macOS."

Meanwhile php developers using macOS have tough time on this.

Until it gets fixed by php upstream, Homebrew adding this environment variable to its php startup script is really providing nice iced water for people in the living hell. I mean, it's usually Mac people using Homebrew. Linux has their own distoro's package manager. Using homebrew for linux is unlikely. Homebrew providing Mac only work-around to its package does sound like it should be. (But of course, upstream fix is ideal. This is just temporary. Please revert this fix after it gets fixed by upstream)

[Saeven]

TLDR; Someone at Apple said "Fork those guys!" ;)

[picov]

@askdkc

In my Intel Mac the file path is /usr/local/Cellar/php/8.2.8/homebrew.mxcl.php.plist.
I've modified that config and restarted php and https but the problem is the same.
In my local dev however, I'm using Apache + PHP as module (Apache 2.0 Handler) thus I'm not sure that the above file has effect.

[askdkc]

@picov

Thank you for your effort!

Could you do me another favor? Sometimes, people get two homebrew.mxcl.php.plist files inside both of :

• /Library/LaunchDaemons/homebrew.mxcl.php.plist
• /Users/YOUR_USER_NAME/Library/LaunchAgents/homebrew.mxcl.php.plist

If you have both files, could you remove

/Users/YOUR_USER_NAME/Library/LaunchAgents/homebrew.mxcl.php.plist one

Then restart your Mac. And see if it fixes the problem or not?

[liyandong-poper]

@askdkc

Same as @picov.

My: Intel Mac + Monterey + php8.2 + valet + postgresql

I confirmed:

• No homebrew.mxcl.php.plist in /Users/YOUR_USER_NAME/Library/LaunchAgents/homebrew.mxcl.php.plist;

• Added OBJC_DISABLE_INITIALIZE_FORK_SAFETY in /Library/LaunchDaemons/homebrew.mxcl.php.plist like you say;

• Restarted my mac.

But the problem is the same (nginx 502).

I have read your all comments in laravel/valet#1433.

But it's not solved this problem that has been bothering me for 3 days, can't work.

What information can I provide to help solve it?

brew -v
Homebrew 4.1.2
Homebrew/homebrew-core (git revision 9d1199551c3; last commit 2023-07-28)
Homebrew/homebrew-cask (git revision 2a1409f952; last commit 2023-07-27)

[askdkc]

@liyandong-poper

If you are using Valet with PostgreSQL like me, try this mattstauffer comment instruction: laravel/valet#1433 (comment)

Perhaps the key point is Delete the php82 sock file (~/.config/valet/valet82.sock) and then valet install again

See how it goes. Good luck!

[picov]

@askdkc
Sometimes, people get two homebrew.mxcl.php.plist files

I've just verified that in my M1 installation the file inside
/opt/homebrew/Cellar/php/8.2.8_1/homebrew.mxcl.php.plist
act as template.
When you do a "brew services restart php" the above file is copied inside
~/Library/LaunchAgents/homebrew.mxcl.php.plist (~ is the active user home folder like '/Users/{username}' )
and used as config to start the service.

I've reconfigured Apache to use PHP as FastCGI/FPM mode (previously it was configured as module in Apache 2 handler mode), edited the file above and restarted the service (and Mac also).
The error is the same when a PHP page use the "_" gettext function.

On an Intel Mac the problem is the same.

[askdkc]

@picov

Interesting.
I also have Intel Mac and my solution is also working on Intel too.

How about try

brew services stop php

rm ~/Library/LaunchAgents/homebrew.mxcl.php.plist

sudo brew services start php

Does it make difference?

Or if it's particular under-bar-gettext thing, try this comment work around.

laravel/valet#1433 (comment)

[picov]

@askdkc

Yes, it make difference!
Starting the the PHP service with sudo solve de problem even if the OBJC_DISABLE_INITIALIZE_FORK_SAFETY in not set in config.
Tested on both Intel and M1 Macs with PHP configured in FPM mode (Server API: FPM/FastCGI).

If PHP is configured as Apache module (Server API: Apache 2.0 Handler) to solve the problem there is the need to start even httpd as root (sudo brew services start httpd).

PS: the _ gettext walkaround with putenv doesn't work.

[askdkc]

@picov

Great! It's nice to see you solved the problem. Congrats!

And it looks like Apache is doing somewhat better job than Nginx in this case. Interesting.

Starting the the PHP service with sudo solve de problem even if the OBJC_DISABLE_INITIALIZE_FORK_SAFETY in not set in config.

Is your /opt/homebrew/Cellar/php/8.2.8_1/homebrew.mxcl.php.plist still have following inside?

<key>EnvironmentVariables</key>
        <dict>
            <key>OBJC_DISABLE_INITIALIZE_FORK_SAFETY</key>
            <string>YES</string>
        </dict>

If so, your /Library/LaunchDaemons/homebrew.mxcl.php.plist also has the same parameter.
Could you check and make sure if it exists or not please? Thanks!

[picov]

@askdkc

My "/opt/homebrew/Cellar/php/8.2.8_1/homebrew.mxcl.php.plist" and my "/Library/LaunchDaemons/homebrew.mxcl.php.plist" not have the OBJC_DISABLE_INITIALIZE_FORK_SAFETY parameter.

[askdkc]

@picov

Thank you for checking.
So in your case, all you needed was just run php using sudo brew services command👍

[liyandong-poper]

@askdkc

If you are using Valet with PostgreSQL like me, try this mattstauffer comment instruction: laravel/valet#1433 (comment)
Perhaps the key point is Delete the php82 sock file (~/.config/valet/valet82.sock) and then valet install again
See how it goes. Good luck!

I have tried the above, but it didn't work. Later, when I was discouraged, I finally thought that this might be a system-related problem, so I tried to upgrade the system to Mac Ventura 13.5.
Amazing, everything works now!

Currently OBJC_DISABLE_INITIALIZE_FORK_SAFETY is still set, I haven't verified whether it is related to this setting (because it is normal after upgrading the system)

anyway thank you!

[askdkc]

@liyandong-poper

Wow!! It's nice to see you finally get it working👍 Congrats!!

[askdkc]

@SMillerDev

Reading GitHub comment doesn't give you an actual number of users who has problem. C'mon.

[drbyte]

Adding putenv("LC_ALL=C"); to my PHP script before any _("") - worked like magic

If fixing an env var that gettext uses solves gettext from crashing upstream, then that suggests there's a bug in gettext.
What changed in gettext's compilation/dependencies lately that's causing it to crash when a simple env var is missing? Shouldn't it fail a little more friendly?

[drbyte]

that would also mean the only way to fix it is dropping the krb5 dependency

What makes the krb5 package a dependency to php? What's it providing? What's lost if it's dropped? What alternatives exist?

[SMillerDev]

Reading GitHub comment doesn't give you an actual number of users who has problem.

Being a full time PHP developer and follower of various related news sources with no mention of this problem anywhere but in this issue gives me an idea though.

[SMillerDev]

What makes the krb5 package a dependency to php?

Kerberos support in the curl, MySQL and IMAP implementations

What alternatives exist?

Leaving PHP users with broken/incomplete cURL, MySQL and IMAP implementations

[askdkc]

Leaving PHP users with broken/incomplete cURL, MySQL and IMAP implementations

Laravel Valet (php-fpm) is working fine with MySQL on this issue which is kinda irony. Using with PostgreSQL or mongodb are having this problem.

BTW Laravel Herd uses Valet under the hood that doesn't have this problem. Herd uses its own php static binary though.

Docker also doesn't have this issue.

I wonder why the Homebrew version only has this issue.

[SMillerDev]

BTW Laravel Herd uses Valet under the hood that doesn't have this problem. Herd uses its own php static binary though.

Docker also doesn't have this issue.

The docker one can't use any system libraries and the static binary probably compiles in a copy of all system libraries so they can't triggers Apple's fork protections like Homebrew's dependency on system components does.

[askdkc]

Yeah, do we really need to follow Apple way? Is it worth? No matter how hard we try, they will just keep changing their rules (like this sudden killing fork process change).

I mean if you can fix it soon that's fine but if this remains the same for long time, it's just bad.

[SMillerDev]

Yeah, do we really need to follow Apple way?

On macOS there is no other way. Apple makes the OS, it gets to decide how it works.

No matter how hard we try, they will just keep changing their rules (like this sudden killing fork process change).

Just to clarify, this is a protection that Apple enabled to avoid programs making potentially devices destroying mistakes.

I mean if you can fix it soon that's fine but if this remains the same for long time, it's just bad.

While I agree it's bad, the only thing Homebrew can do is ship a service that disables the protections. The real fixing has to be done by the developers of either PHP or the MongoDB/Postgres implementations that are failing, so this thread isn't going to bring much difference in the long run.

[drbyte]

> What makes the krb5 package a dependency to php? Kerberos support in the curl, MySQL and IMAP implementations What alternatives exist? Leaving PHP users with broken/incomplete cURL, MySQL and IMAP

Can we (someone) try an altered php build formula that excludes Kerberos as a proof of concept to diagnose that this issue lies in that dependency? And then maybe even try an older version of it as a second layer of testing?

[askdkc]

@drbyte

Can we (someone) try an altered php build formula that excludes Kerberos as a proof of concept to diagnose that this issue lies in that dependency?

You can just do this by following these steps:

1. access to https://github.com/Homebrew/homebrew-core/blob/master/Formula/p/php.rb
2. download php.rb
3. Open and delete this line

   homebrew-core/Formula/p/php.rb

   Line 161 in 9b50dd5

   --with-kerberos

4. compile to install using following command:

brew reinstall php.rb  --build-from-source

FYI: PHP without kerberos still gives you 502.

And if you want to revert your PHP to normal version, just run

brew reinstall php

[drbyte]

FYI: PHP without kerberos still gives you 502.

@askdkc I'm thinking that that's probably because the other packages that are actually crashing are also using the various updates that Homebrew has published since the same time when krb5 was updated.

Rolling back git on the homebrew-core tap to June 19 or 20 may be what's needed in order to do a cleaner simulation. But that would only be useful for confirming where the problem lies ... and if the problem is already confirmed to be changes incorporated into krb5 1.21 then the only benefit to tinkering with homebrew's build would be in the replacement of krb5 with some alternative ... which may or may not help if the related packages that are crashing are crashing because of krb5 too.
... which raises a question: is this something that's fixable by a change to PHP at all? If it's actually an issue with the other apps that are using krb5 then perhaps the only part PHP plays in this whole thing is that it's multi-threaded stuff is rather unstable in its MacOS implementation.

---

That said, given the updates posted by Ken Hornstein and krb5 maintainer Greg Hudson, I wonder if time would be better spent exploring their suggestions:

It might be possible to work around this problem in configuration by using a FILE credential cache instead of the default API ccache type.

As Greg mentioned, if you do NOT require Apple credential cache integration then using a different credential cache type (like FILE if you require credential cache sharing across processes, or MEMORY if you do not) is always an option.

Is "work around this problem in configuration" something that can be done in the PHP build? Or even post-build as an env var or an .ini setting?

Unfortunately I'm at the edge of my understanding on how to "do" this. So I'm now just asking questions to help bring up ideas with which someone with more applied knowledge of this may arrive at a solution.

[dentarg]

If it is Postgres that's the problem, there's PGGSSENCMODE=disable, see ged/ruby-pg#311 (comment) for some more info on it. (That worked well for my Ruby app.)

[Krassmus]

For me setting putenv("LC_ALL=C"); in the beginning of my script was the only thing that worked. And that is although my environment was LC_ALL=de_DE.UTF-8. If I set it in the script to that it works as well. Looks to me like gettext doesn't get the environment variables from the OS properly anymore. For me the error occurred since I made an brew upgrade and tried to install php 8.2. But after that my php-gettext crashed even in older PHPs.

[danielcommesse]

Following @dentarg advice, I've finally found a solution that works for Postgres even after a reboot. Although this still errors with echo gettext("hello");, so it's only a solution for Postgres.

In /usr/local/etc/php/8.2/php-fpm.d/www.conf after the following:

; Pass environment variables like LD_LIBRARY_PATH. All $VARIABLEs are taken from
; the current environment.
; Default Value: clean env
;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp

Add an environment variable like this:

env['PGGSSENCMODE'] = disable

Then restart php. This will work even after a reboot.

Tested this working in php 8.2 and 7.4.

UPDATE: If you're using laravel/valet the file should be /usr/local/etc/php/8.2/php-fpm.d/valet-fpm.conf as pointed here: laravel/valet#1433 (comment)

[mariansedivy]

For me on Apple M2 also adding putenv("LC_ALL=C"); at the beginning of the script helped. Thank you!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[drbyte]

This topic is not stale. The problem is still prominent.

[SMillerDev]

There seem to be multiple fixes, but none would work as a patch for Homebrew.

[omarks]

After initially resolving this issue by (I think) adding OBJC_DISABLE_INITIALIZE_FORK_SAFETY key to the plist file, I'm encountering it again. But, if I disable Wifi everything works fine. When Wifi is on (connected to corporate Wifi or hotspot) it does not.

I think I've tried everything that's detailed in this thread.

Apple M1 Pro
Ventura 13.5
Trying to use Symfony local server

Any help appreciated, it's driving me mad!

[steinmb]

• Intel MacOS
• MacOS 14.0 (23A344)
• PostgreSQL 15
• PHP 8.0, 8.1 and 8.2.
• httpd: stable 2.4.57 (bottled)
• openssl@3: stable 3.1.3 (bottled)

signal 11

/usr/local/opt/php@8.1/sbin/php-fpm --nodaemonize

[15-Oct-2023 13:34:27] WARNING: [pool www] child 95449 exited on signal 11 (SIGSEGV) after 9.317275 seconds from start
[15-Oct-2023 13:34:27] NOTICE: [pool www] child 95455 started
[15-Oct-2023 13:34:32] WARNING: [pool www] child 95450 exited on signal 11 (SIGSEGV) after 13.823725 seconds from start
[15-Oct-2023 13:34:32] NOTICE: [pool www] child 95460 started

As soon as I do new PDO() PHP dies. Testet setting PGGSSENCMODE=disable in my local env. before launching it did no change.

If I start PHP as root it works as expected:

sudo /usr/local/opt/php@8.1/sbin/php-fpm --nodaemonize

Edit: Also setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES before launching did nothing for me.

[steinmb]

Ref my previous post above - #137431 (comment)

This worked for me: Add the following lines to your /usr/local/etc/php/<PHPVERSION>/php-fpm.d/www.conf Example /usr/local/etc/php/8.4/php-fpm.d/www.conf

;Signal 11 workaround
env['PGGSSENCMODE'] = disable
env['LC_ALL'] = C

And restart your effected PHP service, or test in running it directly: /usr/local/opt/php@8.4/sbin/php-fpm --nodaemonize

Needed this on all mine PHP versions, to make it work:

• PHP 7.4
• PHP 8.0
• PHP 8.1
• PHP 8.2
• PHP 8.3
• PHP 8.4

[6502nmos]

I've had this problem on my dev Mac (M1) Version 14.0 of a 502 error from nginx when accessing postgres database using php in a symfony app. All three (php, nginx, postgres) are standard homebrew installs.

php-fpm.log entry:

[pool www] child 65967 exited on signal 11 (SIGSEGV) after 1372.087190 seconds from start

The fix by @steinmb has got things working again.

[oyvind-stromsvik]

For me this started happening after my intel iMac automatically upgraded to MacOS 14 Sonoma. Or I can't remember exactly in what order things happened, but I at least upgraded homebrew after the automatic OS upgrade due to homebrew complaining about an unknown OS version and brew services list not listing any services, but at least from that point on I started seeing this error.

I'm running MySQL, PHP, nginx, and every single of my PHP projects are Drupal projects. This error was happening consistently, but on so few pages I was ignoring it for a while, but when it finally bothered me enough to investigate I tracked it down to a dgettext call.

I want to say that out of all the proposed solutions here the LC_ALL=C one was the only one that worked for me, but I actually can't say for sure because that was the last one I tried, and I'm now running that one on top of this one from #137431 (comment):

        <key>EnvironmentVariables</key>
        <dict>
            <key>OBJC_DISABLE_INITIALIZE_FORK_SAFETY</key>
            <string>YES</string>
        </dict>

One thing I will note is that adding putenv("LC_ALL=C"); to index.php instantly solved it, but doing what #137431 (comment) suggests actually solved nothing until I rebooted my entire Mac. Just restarting PHP seemingly did not make that take effect.

At least it seems to work again now, and without me needing to manually alter each script/project, or run services as sudo 🤞

I also have an M1 Macbook at work with a pretty identical setup. I'll double check that tomorrow, and see if I'm seeing this problem there or not.

Edit: Same problem on my M1 Macbook, but there just restarting PHP after doing #137431 (comment) worked. I only need to add env['LC_ALL'] = C, probably because I'm not using PostgreSQL?