Description of problem: When trying to create a Remote Execution job that is set as 'Schedule future execution' instead of 'Execute now', the job is never run, regardless of time/date chosen. Version-Release number of selected component (if applicable): Satellite 6.2.2.1: rubygem-smart_proxy_remote_execution_ssh-0.1.2-2.el7sat.noarch tfm-rubygem-foreman_remote_execution-0.3.0.12-1.el7sat.noarch tfm-rubygem-smart_proxy_remote_execution_ssh_core-0.1.2-1.el7sat.noarch How reproducible: 100% Steps to Reproduce: 1. Create a REX job for any command / system. 2. For Schedule, choose: 'Schedule future execution' and set time a few minutes in the future. 3. Await for the scheduled time to pass, and notice that the job stays in the 'queued' status under Monitor -> Jobs. Actual results: Job stays in 'queued' status under Monitor -> Jobs, is never canceled or moved. (Even if specifying a cancel time as part of rules) If we goto the job itself and click 'Job Task', the task has an error/traceback: Oops, we're sorry but something went wrong undefined method `join' for "N/A":String Expected results: REX Job should create a task and execute at desired time set. Additional info:
the first thing to check would be if there is a "delayed_executor" running. It is the thing that handles running scheduled tasks in Dynflow. One way to do that would be opening the Dynflow console, in the "Status" tab[1], clicking "check status" and checking if any of the entries has "delayed_executor" => true in the meta column and is marked as valid. The CLI equivalent would be running: cat <<-END | foreman-rake console states = ForemanTasks.dynflow.world.worlds_validity_check(false) ForemanTasks.dynflow.world.coordinator.find_worlds.map do |world| world.meta.merge(:valid => states.fetch(world.id, :invalid)) end END This should print the same information as in the Dynflow console, so the same check should be done here. If there is no entry with delayed_executor or the world with it is invalid, restarting foreman-tasks service should fix it. Hope this helps or at least helps us get some more information about what's going on. [1] https://fqdn.of.the.satellite.server/foreman_tasks/dynflow/worlds
It looks like the cause of this BZ is directly tied to the issue in BZ 1390931. Once I applied the workaround: https://bugzilla.redhat.com/show_bug.cgi?id=1390931#c2 Everything was able to proceed at planned scheduled times completely without issue. Thanks for the help, Ivan.
Closing since this is merely a symptom of another issue which is being handled in BZ#1390931