Bug #86941

Logger instances in scheduler tasks are deserialized with outdated paths

Added by Helmut Hummel 4 months ago. Updated 11 days ago.

Status:
Needs Feedback
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-11-16
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Scheduler serializes tasks and stores them in the database.
If these tasks store a logger instance (e.g. by using the LoggerAwareTrait), this instance will be serialized as well and will point to the wrong path, e.g. when TYPO3 is moved to a different folder
or path changes due to deployments.

This issue became much more prevalent with the addition of LoggerAwareTrait to \TYPO3\CMS\Scheduler\Task\AbstractTask
Now every single task will store outdated logger instances pointing to very likely broken directories


Related issues

Related to TYPO3 Core - Bug #87094: A Symfony Console based scheduler task can't be executed and breaks the scheduler module Resolved 2018-12-07
Related to TYPO3 Core - Bug #87261: Upgrade wizard for scheduler tasks with invalid Logger instance paths Under Review 2018-12-21
Related to TYPO3 Core - Bug #87780: Extbase Task should call parents __sleep and __wakeup Methods Resolved 2019-02-25
Related to TYPO3 Core - Bug #86785: Calling scheduler command on CLI throws error if not in /var/www/html Resolved 2018-12-21

History

#1 Updated by Josef Glatz 2 months ago

  • Related to Bug #87094: A Symfony Console based scheduler task can't be executed and breaks the scheduler module added

#2 Updated by Josef Glatz 2 months ago

  • Related to Bug #87261: Upgrade wizard for scheduler tasks with invalid Logger instance paths added

#3 Updated by Achim Fritz 23 days ago

  • Related to Bug #87780: Extbase Task should call parents __sleep and __wakeup Methods added

#4 Updated by Benni Mack 11 days ago

  • Related to Bug #86785: Calling scheduler command on CLI throws error if not in /var/www/html added

#5 Updated by Benni Mack 11 days ago

  • Status changed from New to Needs Feedback

Hey Helmut,

thanks for your report.

Is this fixed with #86785 - https://review.typo3.org/59237 ?

#6 Updated by Helmut Hummel 11 days ago

@Benni: Depends how you look at it. https://review.typo3.org/#/c/Packages/TYPO3.CMS/+/59800/ shows, that the implemented solution needs adaption in all scheduler tasks that implement __sleep and/or __wakeup. e.g. AbstractSolrTask implements __sleep which does not reset the logger, which leads to the logger to be serialized again and not properly set in __wakeup because the logger is only restored when property is null.

Thus https://review.typo3.org/#/c/Packages/TYPO3.CMS/+/59259/ appeared, which introduces an upgrade wizard to remove the logger from serialized tasks, which basically needs to be run all the time, not only once so that solr tasks have a proper instance.

This is why I proposed several times to remove the logger in \TYPO3\CMS\Scheduler\Task\AbstractTask::unsetScheduler and restore it in \TYPO3\CMS\Scheduler\Task\AbstractTask::setScheduler, which solves all issues (makes 59259 obsolete) and also is a more stable solution as it is much more unlikely that custom task implementations override unsetScheduler and setScheduler methods.

So yes, it is partly solved, but the solution is not as robust as it could be. I would do a change request, but since my comments were ignored as of now, I didn't feel like fighting for this one.

Also available in: Atom PDF