Improve cron error logging #32690
Improve cron error logging #32690
Conversation
|
Hi @fredden. Thank you for your contribution
❗ Automated tests can be triggered manually with an appropriate comment:
You can find more information about the builds here ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review. For more details, please, review the Magento Contributor Guide documentation. 🕙 You can find the schedule on the Magento Community Calendar page. 📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket. 🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel ✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel |
magento-engcom-team
added
Component: Cron
Component: Shell
Release Line: 2.4
Partner: Fisheye
partners-contribution
gabrieldagama
added
the
Priority: P3
|
The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time. |
|
The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time. |
|
The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time. |
|
The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time. |
|
I can confirm this issue has caused a problem with monitoring for one of our clients. |
@evktalo I'm having a little trouble interpreting your statement. Are you saying that (1) you have applied the changes in this pull request to a website and these have caused a problem somehow? Or, are you saying that (2) you have witnessed the issue that this pull request aims to solve? |
|
The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time. |
|
@magento run all tests |
|
@magento run Functional Tests B2B, Functional Tests CE, WebAPI Tests |
|
The functional B2B and CE failures are different in recent 2 builds, seems to be flaky, not related to PR. Functional B2b Run 1: |
|
The Web API tests seems to be a known failure. Not related to this PR. |
|
Once semver version will get release and all the related updation will be done we will take this PR further, till then moving this PR to On Hold. |
m2-community-project
bot
added
Progress: on hold
and removed
Progress: extended testing
labels
|
@magento run all tests |
|
As mentioned here, the semver version will get release in upcoming month, post that we can take this PR further. |
|
@magento run all tests |
|
@magento run all tests |
|
@magento run all tests |
|
The semver version updation mentioned here, has been done in https://github.com/magento-commerce/magento2-infrastructure/commit/cb8dbe8c793a290c35ef345757719b9e77edb749. As the SVC is green and all the related PRs got merged, moving this PR back to Extended testing. |
|
@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE, Unit Tests |
|
@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE |
|
@magento run all tests |
|
@magento run all tests |
|
The functional EE failures in recent 2 builds on same code are not consistent. The failures are not part of PR or not failing because of the PR changes, seems to be flaky. 
|
|
One test failure in Functional CE is consistent in recent 2 builds, other failure is not consistent. The VerifyDefaultWYSIWYGToolbarOnProductTest failure is caused because of the known issue and not failing because of PR. 
|
|
@magento run Functional Tests B2B |
|
The consistent Functional B2B failures in recent 2 builds, are not part of PR or not failing because of PR changes. Both the test failures are known issues, hence seems to be flaky. Moving this PR to Merge in Progress. 
Known issues: |
Description (*)
This pull request improves logging of errors within cron processes.
Current scenario
Currently any error messages are lost / not recorded. For the main group (and any groups not set to use a separate process), STDERR is left for the scheduler to capture. This is most easily caught with the
MAILTO=directive on unix, however experience suggests this is rarely configured usefully. Any cron group currently configured to run in a separate process will have its STDOUT and STDERR lost forever.Proposed scenario
With the changes here, both STDERR and STDOUT are caught and logged. This is very valuable in scenarios where one cannot configure the scheduler, or when a job running in a separate process is suffering from errors. A good example of this is Magento Cloud hosting where cron processes often fail without any useful diagnostic information available. These changes will mean that STDERR output is readily available, aiding in diagnostics.
Related Pull Requests
Fixed Issues (if relevant)
None
Manual testing scenarios (*)
indexer_reindex_all_invalidphp bin/magento cron:runwithout these changesphp bin/magento cron:runwith these changesvar/log(in this example,var/log/magento.cron.index.log)Questions or comments
I can see that using
posix_isatty()is discouraged, but no alternative is provided / suggested. There are functions in packages installed via composer as development dependencies which provide the required functionality. (eg here and here) What's the recommended approach in this case? Do we simply remove the output line altogether?Contribution checklist (*)
Resolved issues: