Bug 1069210 - External watchdog expires when time is moved month backward or forward
Summary: External watchdog expires when time is moved month backward or forward
Keywords:
Status: CLOSED DUPLICATE of bug 639255
Alias: None
Product: Beaker
Classification: Retired
Component: beah
Version: develop
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-24 13:22 UTC by David Spurek
Modified: 2018-02-06 00:41 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-02-24 22:22:50 UTC
Embargoed:


Attachments (Terms of Use)

Description David Spurek 2014-02-24 13:22:08 UTC
Description of problem:
External watchdog expires when time is moved a month backward or forward. System time is changed back at the end of the same phase.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.run test in beaker where time is changed a month backward or forward.
2.
3.

Actual results:


Expected results:


Additional info:
See job https://beaker.engineering.redhat.com/tasks/executed?recipe_task_id=19347261&recipe_task_id=19347273 for example of previously mentioned problem.

Comment 1 Dalibor Pospíšil 2014-02-24 13:59:03 UTC
The watchdog should use an independent or semi-independent time measurement. Something like 'timeout=10; while let timeout--; do sleep 1; done' instead of something like 'sleep $timeout'

Comment 3 Dan Callaghan 2014-02-24 22:22:50 UTC
The external watchdog is unaffected by the system clock (the external watchdog is managed by Beaker). The problem you are seeing is presumably bug 639255, where the harness does not correctly handle shifts in the system clock.

*** This bug has been marked as a duplicate of bug 639255 ***


Note You need to log in before you can comment on or make changes to this bug.