apachectl graceful causes SIGSEGV with latest PHP 8.1.x and PHP 8.2.x

Wondering if anyone else seeing this?

Building from ports (just because that's what I've always done) - FreeBSD 13.1 (or 13.2) on amd64, Apache 2.4.56 or 2.4.57, PHP 8.2.4 (and 8.2.5) both exhibit the behaviour, as do 8.1.17 and 8.1.18.

mod_php82 (or 81).

Noticed when logs rotated, but further digging showing it's effectively the apachectl graceful causing my problems. After an apachectl graceful you'll have stopped serving web pages. apachectl restart is fine.

Apache and mod_php82 were fine, so I started adding a few extensions and got it to start happening. Thought it was cURL for a while but that didn't make any difference.

I seem to have got it down to two options (a) disable opcache in php.ini or (b) build PHP and mod_php with ZTS - but I'm not sure where either of those paths will lead me.

PHP 8.2.3 seems to be the last version that works. There were messages like this but other than that no obvious ill-effects:
Code:
Apr 17 13:42:58 development kernel: pid 7734 (httpd), jid 0, uid 0: exited on signal 11 (core dumped)
Which is what I think someone was trying to fix in PHP - leading to changes in 8.2.4 and 8.2.5. But for me they've made things worse.

Anyway at this point - anyone else seeing this?

(Plenty of people seeing similar things but mostly "just use nginx" responses etc. that aren't very helpful).

EDIT: what pointed the figure at opcache (apart from other discussions on the internet):
Code:
root@r220:/usr/ports/lang/php82 # lldb /usr/local/sbin/httpd -c /httpd.core
(lldb) target create "/usr/local/sbin/httpd" --core "/httpd.core"
Core file '/httpd.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'httpd', stop reason = signal SIGSEGV
  * frame #0: 0x0000000837692220
    frame #1: 0x000000083a211ee2 opcache.so`___lldb_unnamed_symbol1035 + 66
    frame #2: 0x000000083d898446 libphp.so`___lldb_unnamed_symbol8334 + 22
    frame #3: 0x000000083d879a02 libphp.so`zend_llist_apply_with_del + 82
    frame #4: 0x000000083d817321 libphp.so`php_module_startup + 2433
    frame #5: 0x000000083d977dc6 libphp.so`___lldb_unnamed_symbol10022 + 118
    frame #6: 0x00000000002620df httpd`ap_run_post_config + 79
    frame #7: 0x000000000025d83a httpd`main + 2426
    frame #8: 0x000000000025ccc0 httpd`_start + 256
(lldb)
 
Fwiw I'm seeing the same thing on FreeBSD 13.2-RELEASE with pkg's apache24-2.4.56 and mod_php80-8.0.28_1.

From dmesg: pid 50432 (httpd), jid 0, uid 0: exited on signal 11 (core dumped)

I noticed apache always crashed when certbot attempted to renew certificates, but now presume it's also crashing when apache log files are rotated. I have found "sudo apachectl graceful" always causes apache to crash.

I've enabled mod_mpm_prefork and other than mod_php (libphp.so), I think the only other modules intentionally activated are mod_rewrite and mod_ssl.

Thanks richardtoohey2 for note re opcache, I disabled opcache in php.ini and "apachectl graceful" now does not result in a crash. Fwiw I had changed some opcache parameters (per direction from Nextcloud iiuc) - opcache.memory_consumption=256 and opcache.interned_strings_buffer=32 - but can't say if enabling opcache with default settings still crashes. I also haven't tried disabling ASLR either. So far, I'll live with php opcache disabled.
 
Keep an eye on the bug report - looks like it’s slowly rumbling to a conclusion:


I can’t find the link anywhere (thought it was in that bug report) about ASLR and opcache on Debian (IIRC) so it seems to be a known thing that opcache doesn’t work with.

In the meantime yes either disable opcache or avoid graceful or guess you can try the ASLR-off patch and rebuild Apache.
 
same here after OS update 13.1-REL to 13.2-REL with apache24-2.4.57_1 and php74-7.4.33 (all via pkg)

on 13.1 all was OK, but just after upgrade to 13.2, same beahviour - after graceful restart (at 00:00 after log rotation), it crashes

Aug 17 01:09:54 www kernel: pid 4779 (httpd), jid 0, uid 0: exited on signal 11 (core dumped)

restart is fine too

so thanks to all comments here, got it what is it about, went the way disabling ASLR in loader.conf

but would not expect this serious change in minor OS upgrade :-/
 
I think mod_php is well past its sell-by-date (and incidents like this are a nudge to consider alternative) but its very easy-to-use.
 
I think mod_php is well past its sell-by-date (and incidents like this are a nudge to consider alternative) but its very easy-to-use.

I don't know about that, mod_php is great at what it does, has excellent performance, integrates very nicely with the web server, and works elegantly with jails. On the other hand, things like ASLR really don't add much. I'd rather disable that than walk away from mod_php. I tried PHP FPM and you loose so much and gain, well pretty much nothing.

Code:
sysrc -j $JAIL_NAME apache24_aslr_disable="YES"

Besides, no one should be running Apache or PHP outside a jail these days.
 
Back
Top