Req #76225 [Opn]: ini setting to not empty opcache when php-fpm is reloaded

Edit report at https://bugs.php.net/bug.php?id=76225&edit=1 ID: 76225 Updated by: nikic@php.net Reported by: post at minhost dot no Summary: ini setting to not empty opcache when php-fpm is reloaded Status: Open Type: Feature/Change Request Package: opcache Operating System: CentOS 7.4 PHP Version: 7.1.16 Block user comment: N Private report: N New Comment: SIGABRT (most likely) indicates that an assertion failure occurred. These only happen in debug builds, so it's expected that you see a different behavior in non-debug builds. SIGABRT should also be generating core dumps. I'm not sure why this doesn't work for you. One more thing to check would be if you have the rlimit_core option specified in an fpm pool config. It should be either not present at all, or set to rlimit_core=unlimited. Previous Comments: ------------------------------------------------------------------------ [2018-04-23 18:59:29] post at minhost dot no The crazy thing is that on the test server with a copy of the sites from production server, I only get SIGABRT in php-fpm.log when php-fpm/opcache crashes, but on the production server I get SIGSEGV in php-fpm.log when php-fpm/opcache crashes on the same sites. ------------------------------------------------------------------------ [2018-04-23 18:52:12] post at minhost dot no Please note that whenever php-fpm/opcache crash, it causes a SIGABRT in php-fpm.log like this: [23-Apr-2018 20:35:50] WARNING: [pool asle] child 949 exited on signal 6 (SIGABRT) after 169.991198 seconds from start And no core dump file is generated in /tmp - is it because it is a SIGABRT and not a SIGSEGV? Should I be able to get a core dump file on crash with SIGABRT? ------------------------------------------------------------------------ [2018-04-23 10:57:22] post at minhost dot no I was able to get one step closer to generating core dumps. It seems I needed to add the following to /etc/security/limits.conf: * soft core unlimited After doing that I was able to get a core file in /tmp when running this command: kill -s SIGSEGV $$ However when php-fpm/opcache crash, there is still not generated any core files in /tmp I have even changed PrivateTmp=true to be PrivateTmp=false - but still no luck. ------------------------------------------------------------------------ [2018-04-20 18:23:02] post at minhost dot no On the test server I have managed to crash two test sites now Some observations I have done now, is that each time I get crash on the test server, it is no more free memory in opcahe, like this (the test server does not have a lot of memory): Used memory 134214488 Free memory 3240 However on the production servers, I have allocated 32 GB to opcache, and I have never seen it use more then 9 GB in opcache. However I am not sure how opcache user the memory limit I set, because the 32 GB is not visible when looking at used memory in shell: [root@production-server ~]# free -m total used free shared buff/cache available Mem: 128658 14825 1961 6672 111870 106292 Swap: 955 954 1 Could it be that opcache is not able to allocate memory from the already used buffer/cache above? Or is the 32 GB memory limit in opcache already accounted for in the current buffer/cache? Anyway, I am still not able to get any dump files in /tmp on the test server. ------------------------------------------------------------------------ [2018-04-20 16:02:40] post at minhost dot no By the way, when I manually double check by looking into the file: /proc/sys/kernel/core_pattern It correctly has this content: /tmp/core-%e.%p And looking into: /proc/sys/kernel/core_uses_pid It correctly has this content: 0 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76225 -- Edit this bug report at https://bugs.php.net/bug.php?id=76225&edit=1