R81.20 Jumbo Hotfix Accumulator take #76 has been released today

[gadt]

Hi All

R81.20 Jumbo Hotfix Accumulator take #76 has been released today, and is available for download.

Please note the following:

•        Availability:

o   Available to download the via Jumbo documentation R81.20 

o   Available for download via CPUSE by using package identifier.

o   Can be provided by customer support

Content included in this take:

• List of resolved issues in this take can be found in the Jumbo documentation R81.20 

Note:

• Central Deployment allows you to perform a batch deployment of Hotfixes on your Security Gateways and clusters from SmartConsole!! For more information, see sk168597.

Thanks,

Release Operations Group

[the_rock]

Just installed it in the lab, API started in 30 seconds 🙂

So far, good!

Andy

[Alex-]

Is it now recommended? I see it in CPUSE as recommended since a few moments but no announcement here and the documentation still shows Take 76 as latest and not recommended. This morning, we could still see Take 65 as recommended.

[MeravAlon]

Hi @Alex- 

We are in a process of making Take 76 recommended. The announcement and documentation will be updated soon. 

Merav

[the_rock]

@Alex- For what its worth, once when customer was going to install recommended jumbo for R81.10, we were on the phone with TAC and they noticed recommended take was higher than one client intended to apply, so TAC guy said whatever shows as such in web UIis always correct, even though doucumentation was "lagging", so probably took bit of time to update.

Best,

Andy

[PetterD]

Anyone have any experience with T76 on VSX ? Currently have a T41 VSX where cpd-process on VS0 keeps restarting and see that PRJ-47797 in T43 and higher solves a vsx-cpd issue. 

[the_rock]

@PetterD For what this is worth (or FWIW as young folks would say : - )), I have a friend who I used to work with and he told me they have a customer who uses VSX and they had this exact problem and TAC suggested to them to install jumbo 76 and there has been no issues for 10 days, so thats pretty solid reason to install it, I would say.

Best,

Andy

[Mattias_Jansson]

We have issues on R81.10 with vsx and cpd that freezes and restarts. TAC told me a fix will be avaliable soon. 
I just noted that it is in the list of upcoming resolved issues for R81.20 (PRHF-33572 - In rare scenarios, the CPD process of the default Virtual System on a VSX Gateway (VS0) gets stuck.)

[PetterD]

Thanks @Mattias_Jansson !

In your scenario, does the CPD-process  automatically restart itself aftwerwards ?
In our scenario we can see this issue  going back several  months but increasing in frequency. Now it restarts every 1-2-5  hours and  it takes between 10  minutes and 2 hours before it responds again and it only occurs on VS0 on one of  the VSX-gateways  (VSLS)

When the issue occur we see the following  in cpd.elg

 Cpd started
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] CMS_msg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] ThresholdEngineMsg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] PersistencyAgentMsg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] cxlsync_msg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] cxlsync_msg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] cpd_PA_msg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] EntMgr_initModuleMessagingMechanism_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] EntMgr_initExecuterMessagingMechanism_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] AVSU_msg_register: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] cpd_sched_msg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] WMmsg_cb: Connection to msg deamon has succeeded
[CPD 48158]@fw-vsx-1[8 Jul 11:00:58] [INFO] cpd_msg_cb: Connection to msg deamon has succeeded
 fwstatagent_check_sdwan: Getting sdwan interfaces
 fwstatagent_check_sdwan: Getting sdwan interfaces
 cpd_mon_signal_handler: About to be killed by CP watchdog! Attempting graceful exit...
 check_caller_thread_safe: [WARNING] Non thread safe action: Mainloop thread id = 4132435776 while current thread id = 4043307840 (LWP 48304)
 Backtrace with 10 levels:

 [1] 0xf6d6c7e3 [/opt/CPshrd-R81.20/lib/libComUtils.so] (offset 0xf7e3)
 [2] 0xf6d6d69d [/opt/CPshrd-R81.20/lib/libComUtils.so] (offset 0x1069d)
 [3] T_event_sched_ed [/opt/CPshrd-R81.20/lib/libComUtils.so] (offset 0x118c0)
 [4] T_event_sched_e [/opt/CPshrd-R81.20/lib/libComUtils.so] (offset 0x119a0)
 [5] opsec_schedule [/opt/CPshrd-R81.20/lib/libopsec.so] (offset 0x18f30)
 [6] cpd_stop [cpd] (offset 0x5530)
 [7] cpd_mon_signal_handler [cpd] (offset 0x56c0)
 [8] __kernel_sigreturn [] (offset 0x400)
 [9] __kernel_vsyscall [] (offset 0x420)
 [10] pthread_cond_timedwait [/lib/libpthread.so.0] (offset 0xa580)
[CPD 73454 4131866432]@fw-vsx-1[8 Jul 11:13:40] CPD: Mon Jul  8 11:13:40 2024

 
 ==============================
        Cpd Initializing
 ==============================

[Mattias_Jansson]

Yes, same scenario here. The issue seems to grow in time. We usually restart the vsx-gateway when the the errors are too frequent.