R81.20 - Waiting for another automatic update to finish

[Mikael]

Hello,

During upgrades to R81.20 I have on multiple occasions got stuck while trying to add a JHF with "Waiting for another automatic update to finish".

Sometimes the issue is resolved by stoping and starting DAagent (installer agent stop, installer agent start), sometimes I have to install something else (SmartConsole update), sometimes I have to remove the JHF and add it back manually.

I know of other colleagues that are facing the same issue during upgrades.

Has anyone found a more reliable solution?

With my approach it's more of a guessing-game what will solve the issue for the current upgrade...

Cheers

[nicolasr]

Hi @Mikael ,

can you tell please, in which version you are, which setup it is, and which package are you trying to import?

If i understood correct, the issue is when importing when you are saying "adding"?

[Mikael]

So far it’s mainly been management servers and log-servers running R81.10 with random JHF’s. 
The issue occurs after upgrading to R81.20 and when we try to apply the current JHF. I have seen it with JHF24 and with JHF26. 

The problem occurs regardless if the JHf was automatically downloaded from the cloud or manually imported. 

When looking at the DA_action.xml there is nothing that looks strange. No other update that hasn’t finished. DA agent itself is the latest version. 

Not sure what other updates that might interfere with the DA agent. 

[nicolasr]

What you mean by "apply" or "add"? you mean during the import? or during the installation?

[nicolasr]

@Mikael Can you also tell please, what is the package name that you have performed the upgrade to R81.20?

[Mikael]

Check_Point_R81.20_T631_Fresh_Install_and_Upgrade.tar via https://support.checkpoint.com/results/download/124401

[Mikael]

The issue occurs once we click install on the JHF...

[svori]

Hi

The same issue happened to me, i solved by kill the process in expert mode.

Name of the process starts with DA.

expert: ps fauxww| grep -i da

then

kill -9 (insert pidhere)

This was together with a TAC engineer.

[the_rock]

I never had this issue happened to me and I cant even count how many upgrades I had done. I always make sure DA is set to auto update.

Andy

[Arthur_DENIS1]

Hello

Still have the same issue, and it's not the first time....

It's maybe time for Checkpoint to provide us another upgrade package with a fix !

[G_W_Albrecht]

What one can guess looking at top is that a SMS will take some time after an upgrade to be full up and running (and  able to install JHFs) and SSH, GAiA WebGUI and Dashboard can connect. The ca. 20mins are a good estimate 😉

[Mikael]

The management-server is up and running when this happens so I don't think it has anything to do with that part.

And the issue is not always solved by stopping and starting DA agent, regardless if it's via "installer agent stop", "installer agent start" or by killing the process in bash...

Sometimes I have to install something else and sometimes that doesn't work either...

So there must be something else hidden somewhere causing this automatic update failure.

[ishuyell]

I had to reboot for this to resolve. Then  hotfix installation was failing with failed with error "The previous installation of this package terminated abnormally" so delete this package and manually imported the hotfix and installed the fix.

[Axel_Winterberg]

I have upgraded the management from R81.10 to R81.20.  Then tried to install JHF T26. Error message  "Waiting for another automatic update to finish". After Reboot, ...  "The previous installation of this package terminated abnormally" .

So, I have deleted the package, downloaded it again and were able to install it successfully!  🙂

[Bob_Zimmerman]

I get this all the time immediately after upgrades to a new version. Got it when upgrading to from R80.40 to R81.10 (Check_Point_R81.10_T335_Fresh_Install_and_Upgrade.tar), and getting it again when upgrading from R80.40 or R81.10 to R81.20 (Check_Point_R81.20_T631_Fresh_Install_and_Upgrade.tar). We end up simply waiting ~20 minutes after an upgrade before we try to install the jumbo.

I always assumed it was the deployment agent updating itself, fetching the package list from Check Point, or something like that. It has been mildly annoying, but not so bad I could justify the time to hunt down the cause.

[Pedro_Madeira]

I'm still getting this problem a lot, especially in management machines.

Many times when I upgrade to R81.20 and after the management upgrade tasks finish, I have a hard time installing the jumbo.

Most times I notice that autoupdatercli is dormant but I still get the "Waiting for another automatic update to finish" message. If I do a reboot, when the machine comes up, I see autoupdater resuming its updating tasks and then I'm able to launch the jumbo.

I'm currently facing an harder to solve issue, this is with a full-ha cluster (mgmt+fw) where everything I tried failed to successfully launch the jumbo installation.

After a reboot, I'm going to try to delete the jumbo installer, download and try to install it again.

Weird and annoying issue this one

[G_W_Albrecht]

Fact is that you have to wait after upgrading an SMS for some time before installing the Jumbo. Full Management HA is not something i would suggest to anyone...

[Sergio_Alvarez]

I have experienced this issue with two different boxes in two consecutive days, both times trying to install JHF65 over R81.20, both times we waited a fair amount of time before trying to upgrade. The last time, for example, the Management finished upgrading from R81.10 to R81.20, we logged via SmartConsole, verified everything was in place, made sure it was possible to install policy in all managed gateways and also that logs from all gateways were received in real time, then closed SmartConsole, logged via Gaia webUI, generated a snapshot and THEN, finally tried to install JHF65... when the message about "waiting for another automatic update to finish" came up... I would say it was by far, enough time for everything to be in a stable situation.

What really makes me think is if it happened to me twice in 2 days, I'm pretty sure lots of other people have seen it and still, I could not find an SK document about it.  

Both times I had to do what others here mentioned, reboot the SMS, remove the installer (as it said last time finished abnormally), download it again and execute the upgrade again.

[the_rock]

I can only speak for myself...happened once, I did cprestart and worked fine after. This was back in R80.10

Andy

[Daniel_Szydelko]

Hi,

I met the same on management with R81.20 when trying to install JHF Take_65 (on both boxes in HA), so for me worked such solution (reboot doesn't resolve it)

- when hit issue

- reboot

- delete JHF Take_65 package from repository

- download or upload it again

- try to install again JHF

BR

Daniel.

[the_rock]

That definitely works, though when it happened to me while back, I never needed to delete the package from repository.

Andy

[G_Mirabella]

Works!

[AnkitSurati]

This worked and same was suggested by TAC

[Arne_Boettger]

Hello,

during our upgrade to R81.20 we saw the same problem. Apparently, the autoupdater was very busy doing something™ blocking the installer. The process list looked like this for a long time, and it reoccured after a reboot, but then eventually completed.

admin 20151 0.0 0.0 3640 1152 ? SN 14:30 0:00 \_ /bin/bash -c export IS_REVERT=0;export INSTALLED_VERSION=0;export VERSION_TO_IN
STALL=136;/var/log/AutoUpdater/metadata/itp/simplified_threat_prevention/GOT_MGMT_AutoUpdate/136/product_scripts/simplified_threat_prevention_post_actio
n.sh >> /opt/CPInstLog/AutoUpdateLogs/simplified_threat_prevention
admin 20155 0.0 0.0 3644 1544 ? SN 14:30 0:00 \_ /bin/sh /var/log/AutoUpdater/metadata/itp/simplified_threat_prevention/GOT_
MGMT_AutoUpdate/136/product_scripts/simplified_threat_prevention_post_action.sh
admin 22018 0.0 0.0 3644 1412 ? SN 14:31 0:00 \_ /bin/bash /opt/CPInfinityTp/scripts/docker_control.sh start
admin 22022 0.0 0.0 16780 1752 ? SN 14:31 0:00 \_ autoupdatercli enable simplified_threat_prevention