Bug 652649

Summary:	Taskomatic stops working on DST end.
Product:	[Community] Spacewalk	Reporter:	Christoph Maser <christoph.maser>
Component:	Server	Assignee:	Tomas Lestach <tlestach>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	low
Version:	1.1
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-19 15:21:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	723481

Description Christoph Maser 2010-11-12 13:00:23 UTC

Description of problem:
On 2010/10/31 DST ended here, since then taskomatic stopped working. No more log was written, the last log entry was 


INFO   | wrapper  | 2010/10/31 02:56:28 | The system clock fell behind the timer by 429496729600ms.


Version-Release number of selected component (if applicable):
spacewalk-taskomatic 0:1.1.52-1.el5.noarch

Comment 1 Michael Mráka 2010-11-12 13:21:59 UTC

Adding to tracker and reassigning to our taskomatic guy.

Comment 2 Jan Pazdziora 2010-11-19 16:03:34 UTC

Mass-moving to space13.

Comment 3 Miroslav Suchý 2011-04-11 07:32:16 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 4 Miroslav Suchý 2011-04-11 07:36:42 UTC

We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 5 Jan Pazdziora 2011-07-20 11:50:04 UTC

Aligning under space16.

Comment 6 Tomas Lestach 2011-08-19 15:21:24 UTC

Yes, this behavior is actually expected.
The logged information about clock felling behind is not a trouble.

A worse thing is, that quartz library isn't ready for time shifts and they always will cause troubles to scheduling actions. When time is shifted back, quartz library will be inactive for the shifted time and will continue scheduling after time is caught up.
As an example:
A task was scheduled 2:59 and next run is shall be triggered at 3:00. But at 3:00, time gets shifted by an hour back to 2:00. So, quartz keeps waiting for 3:00 to trigger next task.

This isn't the best thing, but we're aware of the behavior. We're not planing to work on the issue. However patches are welcome. Closing as WONTFIX.