System Specifications:
Magento Version: 2.4.8-p3
PHP Version: 8.3
Issue: php bin/magento cron:run executes, generates new schedules and runs. But when the run:corn next fires form what ever source the process crashes or hangs immediately after the first job succeeds (or fails silently), leaving the second version of each job pending jobs in the pending state.
Timing Example: If the Magento schedules a job every minute, and I manually execute php bin/magento cron:run at 1:50 PM, and the cron_schedule table contains pending jobs scheduled from 1:40 PM to 1:49 PM, should the command process:
Only the single oldest job (1:40 PM)?
or
ALL 10 pending jobs (1:40 PM to 1:49 PM) in a continuous loop until the queue is clear or the script times out?
Question 1: Magento Cron Execution Mechanics (Confirmation)
Context: Our cron_schedule table is full of pending jobs (e.g., jobs older than 10 minutes).
Goal: Confirming the expected behavior to prove our crash diagnosis.
Question: If I run php bin/magento cron:run, should that single CLI command process:
Only the single oldest, most recently scheduled job?
ALL pending and scheduled jobs (that are due) in a continuous loop until the queue is clear or the script times out?
Our theory is that running the command should clear all due jobs, and the fact that they remain in pending confirms the script is crashing/segfaulting early in the execution loop.
Question 2: The Persistent Segmentation Fault/Hang
Context: We have performed exhaustive module isolation tests, but the crash persists during job execution. This suggests a conflict outside of app/code.
Diagnostic Steps Taken (ALL performed with full setup:upgrade and cache/code cleanup):
Eliminated All Custom Code: Every custom module in app/code has been disabled, including all Swa_* modules, Ess_M2ePro, and WebShopApps_MatrixRate. The crash during job clearing remains.
Data Integrity Check: A TRUNCATE TABLE cron_schedule followed by a cache:flush allows new schedules to generate, but the system still fails to clear the queue, proving the bug is in the executed code, not the data queue.
Core Integrity: The core code (vendor/ directory) is considered clean, as the system has undergone two successful major version upgrades since its last manual patch/modification.
Core Problem: Since all module code is disabled, the crash must be due to a Segfault or hang in a core Magento job being executed on your specific PHP 8.3 environment.
Question: Given a clean Magento 2.4.8-p3 installation running on PHP 8.3, and the crash occurring during job execution (after the first job runs), where would you advise looking for a Segmentation Fault?
Have you seen conflicts with specific PHP 8.3 extensions (e.g., ioncube, specific versions of Redis/OpCache) that cause a Segfault when executing core cron jobs (like sales_grid_refresh)?
We believe the next step is running strace. Have you interpreted strace output for a cron Segfault before, and what file/class should we watch out for right before the SIGSEGV?
