Skip to content

[Issue] Improve cron error logging #37453

Closed
@m2-assistant

Description

@m2-assistant

This issue is automatically created based on existing pull request: #32690: Improve cron error logging


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 (*)

  1. Artificially introduce a memory leak into a cron job, eg indexer_reindex_all_invalid
  2. Run php bin/magento cron:run without these changes
  3. Observe lack of information about the failure
  4. Run php bin/magento cron:run with these changes
  5. Observe information available in var/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 (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds are green)

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions