Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Starting up PHP-FPM fails with APCu (php-pecl-apcu) enabled. Version-Release number of selected component (if applicable): 5.1.8-4.fc27 How reproducible: Every time. Steps to Reproduce: 1. Install: dnf install php-fpm and php-pecl-apcu 2. Start: systemctl start php-fpm Actual results: [straussd@t560 ~]$ sudo systemctl restart php-fpm Job for php-fpm.service failed because a fatal signal was delivered causing the control process to dump core. See "systemctl status php-fpm.service" and "journalctl -xe" for details. [straussd@t560 ~]$ sudo systemctl status php-fpm.service ● php-fpm.service - The PHP FastCGI Process Manager Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled) Active: failed (Result: core-dump) since Wed 2017-11-15 18:20:04 PST; 2s ago Process: 30609 ExecStart=/usr/sbin/php-fpm --nodaemonize (code=dumped, signal=SEGV) Main PID: 30609 (code=dumped, signal=SEGV) Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: Starting The PHP FastCGI Process Manager... Nov 15 18:20:04 t560.davidstrauss.net php-fpm[30609]: [15-Nov-2017 18:20:04] NOTICE: PHP message: PHP Fatal error: PHP Startup: apc_mmap: mmap failed: in Unknown on line 0 Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Main process exited, code=dumped, status=11/SEGV Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: Failed to start The PHP FastCGI Process Manager. Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Unit entered failed state. Nov 15 18:20:04 t560.davidstrauss.net systemd[1]: php-fpm.service: Failed with result 'core-dump'. Expected results: Successful PHP-FPM startup with APCu. Additional info: Removing or disabling APCu fixes the issue. Commenting out "apc.mmap_file_mask=/tmp/apc.XXXXXX" in /etc/php.d/40-apcu.ini switches APCu to using an anonymous mmap and also works around the issue. Abrt seems unable to create a suitable backtrace (either on my machine or on the hosted Fedora backtrace servers): --- Running report_uReport --- ('report_uReport' completed successfully) --- Running analyze_CCpp --- Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'NO' Analyzing coredump 'coredump' All debuginfo files are available Generating backtrace Backtrace is generated and saved, 32881 bytes --- Running analyze_BodhiUpdates --- Looking for similar problems in bugzilla A notice below says: Reporting disabled because the backtrace is unusable. coredumpctl has more success: [straussd@t560 ~]$ coredumpctl info PID: 28165 (php-fpm) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Wed 2017-11-15 18:06:31 PST (23min ago) Command Line: /usr/sbin/php-fpm --nodaemonize Executable: /usr/sbin/php-fpm Control Group: /system.slice/php-fpm.service Unit: php-fpm.service Slice: system.slice Boot ID: 25eb6c2a86544ff8ada94f8964dd7685 Machine ID: 090dfce8e91946609388331241a392a1 Hostname: t560.davidstrauss.net Storage: /var/lib/systemd/coredump/core.php-fpm.0.25eb6c2a86544ff8ada94f8964dd7685.28165.1510797991000000.lz4 (inaccessible) Message: Process 28165 (php-fpm) of user 0 dumped core. Stack trace of thread 28165: #0 0x00007f5728d8e48e pthread_rwlock_init (libpthread.so.0) #1 0x00007f5714191480 apc_lock_create (apcu.so) #2 0x00007f5714195f34 apc_sma_api_init (apcu.so) #3 0x00007f57141923b7 zm_startup_apcu (apcu.so) #4 0x000056251973b0c4 zend_startup_module_ex (php-fpm) #5 0x000056251973b19c zend_startup_module_zval (php-fpm) #6 0x0000562519748b6a zend_hash_apply (php-fpm) #7 0x000056251973b48a zend_startup_modules (php-fpm) #8 0x00005625196d2b93 php_module_startup (php-fpm) #9 0x00005625197e68c5 php_cgi_startup (php-fpm) #10 0x00005625195aa160 main (php-fpm) #11 0x00007f57291c503a __libc_start_main (libc.so.6) #12 0x00005625195ab63a _start (php-fpm)
*** This bug has been marked as a duplicate of bug 1502303 ***