SSSD scheduled tasks are delayed if a time shift is detected

SUSE Linux Enterprise Desktop 15 SP6
SUSE Linux Enterprise Server 15 SP6
SUSE Linux Enterprise Server for SAP Applica­tions 15 SP6

Systems joined to Active Directory with SSSD may experience delays in SSSD-scheduled tasks, such as dyndns updates, if a time shift is detected.

Upgrade SSSD to version 2.9.3-150600.3.12.1 or later

If time is shifted back all planned tasks in SSSD are delayed by that time difference and SSSD's functionality is limited.
This can be triggered by first machine boot when SSSD is started before tools like chronyd are able to set proper system time.
New patch adds ability to detect time shift to SSSD and fix time schedule for planned tasks.

Logs show that SSSD backend had some issues after start with resolving server names so it was offlined for a short time:

  (2024-08-09 12:47:53): [be[AD]] [fo_resolve_service_done] (0x0020): [RID#1] Failed to resolve server 'dc1.example.com': Could not contact DNS servers
  (2024-08-09 12:47:53): [be[AD]] [set_server_common_status] (0x0100): [RID#1] Marking server 'dc1.example.com' as 'not working'
  ...
  (2024-08-09 12:47:53): [be[AD]] [fo_resolve_service_send] (0x0020): [RID#1] No available servers for service 'AD'
  ...
  (2024-08-09 12:47:53): [be[AD]] [be_run_offline_cb] (0x0080): [RID#1] Going offline. Running callbacks.
  ...
  (2024-08-09 12:47:53): [be[AD]] [be_ptask_disable] (0x0400): [RID#1] Task [Dyndns update]: disabling task

After few seconds it was fixed and resolving worked again:

  (2024-08-09 12:47:56): [be[AD]] [set_server_common_status] (0x0100): [RID#6] Marking server 'dc1.example.com' as 'name resolved'
  ...
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_online_cb] (0x0400): [RID#6] Back end is online
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_enable] (0x0400): [RID#6] Task [Subdomains Refresh]: enabling task
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_schedule] (0x0400): [RID#6] Task [Subdomains Refresh]: scheduling task 36 seconds from now [1723200512]
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_online_cb] (0x0400): [RID#6] Back end is online
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_enable] (0x0400): [RID#6] Task [AD machine account password renewal]: enabling task
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_schedule] (0x0400): [RID#6] Task [AD machine account password renewal]: scheduling task 154 seconds from now [1723200630]
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_online_cb] (0x0400): [RID#6] Back end is online
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_enable] (0x0400): [RID#6] Task [Dyndns update]: enabling task
  (2024-08-09 12:47:56): [be[AD]] [be_ptask_schedule] (0x0400): [RID#6] Task [Dyndns update]: scheduling task 94 seconds from now [1723200570]

Here was planned a task to call dyndns update in 94 seconds (1723200570 is Fri Aug  9 12:49:30 PM CEST 2024), however shortly after that was the time shifted 2 hours back.
Therefore all planned tasks mentioned above had to wait another 2 hours before execution.

  (2024-08-09 12:47:56): [be[AD]] [ad_online_cb] (0x0400): [RID#6] The AD provider is online
  (2024-08-09 10:48:04): [be[AD]] [watchdog_fd_read_handler] (0x3f7c0): Time shift detected, restarting watchdog!
  (2024-08-09 10:48:04): [be[AD]] [watchdog_fd_read_handler] (0x3f7c0): SIGUSR2 sent to be[AD]

Timeshift is detected and backend got SIGUSR2 signal. It is already online now so there is logged no reaction.

  (2024-08-09 10:49:09): [be[AD]] [dp_get_account_info_send] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=ad admin server linux@ad]
  ....

There is no dyndns logs until two hours later when the planned task is started:

  (2024-08-09 12:49:30): [be[AD]] [be_ptask_execute] (0x0400): [RID#6] Task [Dyndns update]: executing task, timeout 86400 seconds
  (2024-08-09 12:49:30): [be[AD]] [ad_dyndns_update_send] (0x0400): [RID#6] Performing update

https://bugzilla.suse.com/show_bug.cgi?id=1229128