Project

General

Profile

Actions

Bug #94102

closed

Endless scheduler task execution on PostgreSQL if task_group=NULL

Added by Stephan Großberndt almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2021-05-10
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

I have an issue with the TYPO3 scheduler and PostgreSQL. Apparently the "serialized_task_object" which is unserialized here and saved back to the database here may have the value in the column task_group set to NULL instead of 0.
I have not experienced any issues with that using MySQL but as the SQL definition reads task_group int(11) unsigned DEFAULT '0' NOT NULL, when trying to save the task back in PostgreSQL an SQL error ocurrs:

2021-05-10 12:37:36.332 CEST [22050] foo@bar STATEMENT:  UPDATE "tx_scheduler_task" SET "nextexecution" = $1, "disable" = $2, "description" = $3, "task_group" = $4, "serialized_task_object" = $5 WHERE "uid" = $6
2021-05-10 12:37:36.334 CEST [22050] foo@bar ERROR:  null value in column "task_group" violates not-null constraint
2021-05-10 12:37:36.334 CEST [22050] foo@bar DETAIL:  Failing row contains (2, 1357211168, 0, 1621170900, 1620639799, , CLI, \x4f3a34353a225459504f335c434d535c5265706f7274735c5461736b5c5379..., \x, , null, 0).

And here the real trouble begins: This seems to be executed in a loop by the scheduler endlessly hogging memory and processing power until running out of diskspace. As the task is not marked as "being executed" either multiple instances of the task will be spawned even if the configuration forbids multiple executions at once.

I haven't been able to find out how task_group may become NULL instead of 0, the easy fix would be to re-set the task group to 0 if it is NULL.

Actions

Also available in: Atom PDF