-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reindex by schedule on servers with several PHP versions #3482
Labels
bug report
Issue: Ready for Work
Gate 4. Acknowledged. Issue is added to backlog and ready for development
Comments
Thanks for reporting. Created internal issues for lost output (MAGETWO-49638) and multiple php executables (MAGETWO-49633). |
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - changed Cron to find current php needed if possible - corrected Cron web entry point behavior so both CLI and web entry point Cron behavior is consistent
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - added explicit dependency to symfony/process
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - added explicit dependency to symfony/process in Cron module
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - implemented wrapper for Symfony class
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - changed wrapper class into factory class
magento-team
pushed a commit
that referenced
this issue
Mar 18, 2016
…ly same PHP executable used for running original entry point #3482 - added readme
@mrgoogle the issue with multiple php executables has been fixed in the develop branch. |
This issue was fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug report
Issue: Ready for Work
Gate 4. Acknowledged. Issue is added to backlog and ready for development
Not sure if this can be considered a bug, but finding the reason of the problem and its solution took some time and debugging.
Our customer has two PHP versions on the server: 5.4 for old websites and 5.6 for Magento 2. Web server is set up correctly to use 5.6, but there was a problem with cron tasks.
As it is described in the documentation, I added bin/magento cron:run call to crontab with the correct path to PHP 5.6. And cron tasks from the default group were working fine. However, other group (e.g. index) weren't working.
After some digging I found that for index group Magento2 runs a separate process using the default php binary (Magento\Cron\Observer\ProcessCronQueueObserver::execute()). And since in my case 5.4 is the default PHP ("which php" gives path to it), this separate process fails telling that only PHP 5.5+ is supported. But it tells you that only if you repeat the separate process command - if you run bin/magento cron:run, you just see the usual "Ran jobs by schedule" success message.
Yes, now I know that it can be solved by just setting "Use Separate Process" to "No" for index group in admin, but to find this solution I had to dig through the code, find the command for running the separate process, run it and read the error.
I think that such errors should be written into some log to make it easier for the other people who may meet the same issue. Or set "Use Separate Process" to "No" by default.
The text was updated successfully, but these errors were encountered: