Bug #21361
open
when satellite is starting, there are 4 of "RuntimeError: The Dynflow world was not initialized yet. If your plugin uses it, make sure to call ForemanTasks.dynflow.require! in some initializer" in production.log
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1501949
Description of problem:
when satellite is starting, there are four of "RuntimeError: The Dynflow world was not initialized yet. If your plugin uses it, make sure to call ForemanTasks.dynflow.require! in some initializer" in production.log
Version-Release number of selected component (if applicable):
satellite-6.3.0-19.0.beta.el7sat.noarch
tfm-rubygem-foreman-tasks-0.9.6-1.fm1_15.el7sat.noarch
How reproducible:
always
Steps to Reproduce:
1. Restart system with Satellite and watch production.log while Satellite
is starting
Actual results:
See tracebacks in attached log
Expected results:
There should be no tracebacks
Additional info:
Usually tracebacks during start if everything works after that seems harmless, but this one sugests there might be a way how to suppress it: "make sure to call ForemanTasks.dynflow.require! in some initializer"
Updated by Adam Ruzicka over 7 years ago
- Target version set to 113
Additional notes:
When dynflow world is initialized it invalidates execution plans which still have execution locks. Those execution plans are switched from (usually) running state to paused. When the execution plans are saved with the paused state a callback in foreman-tasks is triggered to update the task object in foreman tasks. This however tries to access ForemanTasks.dynflow.world which is not set at that time.
Also restarting the machine seems like an overkill, the following should be enough to trigger the bug
Steps to reproduce:
1) Start a task
2) Kill foreman-tasks with SIGKILL
3) watch production.log
4) restart foreman-tasks service