Project

General

Profile

Actions

action #124736

closed

[qe-core] PED-3144 - Y2K38 Epochalypse

Added by szarate about 1 year ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2023-03-08
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:
Sprint:
QE-Core: April Sprint 23 (Apr 05 - May 03)

Description

Business reason

See also

https://mailman.suse.de/mlarch/SuSE/research/2023/research.2023.02/msg00063.html

Suggestions

  • Boot an already installed system change the time to few minutes before Y2K38 time, observe
  • Install a system with few minutes before Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Install a system with few minutes after Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Boot an already installed system change the time to few minutes after Y2K38 time, and observe
  • Setup a multi-machine job, where the one that changes the new time is the NTP server.

Subtasks 2 (0 open2 closed)

action #125639: [qe-core] Explore possibilities for a time-shifted test environmentResolvedrfan12023-03-08

Actions
action #127130: [qe-core] Implement a prototype for a time-shifted test environment on TWResolvedrfan12023-03-08

Actions

Related issues 1 (0 open1 closed)

Related to openQA Tests - action #127970: [qe-core][microOS]test fails in year_2038_detectionResolvedrfan12023-04-19

Actions
Actions #1

Updated by szarate about 1 year ago

  • Sprint set to QE-Core: March Sprint (Mar 08 - Apr 05)
Actions #2

Updated by ph03nix about 1 year ago

  • Status changed from New to Workable
Actions #3

Updated by rfan1 about 1 year ago

  • Assignee set to rfan1
Actions #4

Updated by rfan1 about 1 year ago

  • Tracker changed from coordination to action
  • Status changed from Workable to In Progress
  • Boot an already installed system change the time to few minutes before Y2K38 time, observe Done - > I can hit the issue once the time goes to Y2K38 time.
  • Install a system with few minutes before Y2K38 time, and observe (so the installation lands exactly during the moment) N/A -> The latest time I can set is 2031/12/31
  • Install a system with few minutes after Y2K38 time, and observe (so the installation lands exactly during the moment) N/A -> The latest time I can set is 2031/12/31
  • Boot an already installed system change the time to few minutes after Y2K38 time, and observe Done - > I can hit the issue at once if I change the time
  • Setup a multi-machine job, where the one that changes the new time is the NTP server. N/A -> Seems I didn't find a right way to configure a NTP server without sync with internet time
Actions #5

Updated by rfan1 12 months ago

  • Status changed from In Progress to Feedback
Actions #6

Updated by szarate 12 months ago

  • Sprint changed from QE-Core: March Sprint (Mar 08 - Apr 05) to QE-Core: April Sprint 23 (Apr 05 - May 03)
Actions #7

Updated by szarate 12 months ago

  • Tracker changed from action to coordination
  • Target version set to QE-Core: Ready
Actions #8

Updated by szarate 12 months ago

  • Status changed from Feedback to Blocked
Actions #9

Updated by rfan1 12 months ago

  • Tracker changed from coordination to action
  • Status changed from Blocked to Resolved
Actions #10

Updated by szarate 10 months ago

  • Related to action #127970: [qe-core][microOS]test fails in year_2038_detection added
Actions #11

Updated by xgonzo 6 months ago

szarate wrote:

Business reason

See also

https://mailman.suse.de/mlarch/SuSE/research/2023/research.2023.02/msg00063.html

Suggestions

  • Boot an already installed system change the time to few minutes before Y2K38 time, observe
  • Install a system with few minutes before Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Install a system with few minutes after Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Boot an already installed system change the time to few minutes after Y2K38 time, and observe
  • Setup a multi-machine job, where the one that changes the new time is the NTP server.

Have you thought about setting up cron jobs for a time after Y2K38?

Maybe blog of Thorsten Kukuk provides some more ideas for testing:
https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/

Actions #12

Updated by szarate 6 months ago

xgonzo wrote in #note-11:

szarate wrote:

Business reason

See also

https://mailman.suse.de/mlarch/SuSE/research/2023/research.2023.02/msg00063.html

Suggestions

  • Boot an already installed system change the time to few minutes before Y2K38 time, observe
  • Install a system with few minutes before Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Install a system with few minutes after Y2K38 time, and observe (so the installation lands exactly during the moment)
  • Boot an already installed system change the time to few minutes after Y2K38 time, and observe
  • Setup a multi-machine job, where the one that changes the new time is the NTP server.

Have you thought about setting up cron jobs for a time after Y2K38?

Maybe blog of Thorsten Kukuk provides some more ideas for testing:
https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/

We will follow up with the Year 2037 too :)

Actions

Also available in: Atom PDF