Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
burticio
Participant
Jump to solution

Alert message on Policy install after R81 upgrade

Hi, community!

 

I performed a Cluster Upgrade from R80.30 to R81. All worked fine, but lately every time I install the policy I get several alert messages:

"dlopen: /opt/CPsuite-R81/fw1/tmp/install_policy/1a63208f-5060-414e-834c-78ac7c585a54/FW1/lib/libcpatlas.so: cannot open shared object file no such file or directory"

I notice the file libcpatlas.so is being searched in a tmp directory.

 

¿How could I fix this?

 

The policy is installed correctly and all the rules work fine.

 

Thanks!

0 Kudos
1 Solution

Accepted Solutions
Tal_Paz-Fridman
Employee
Employee

After checking with relevant R&D owners, this is a known issue and was just added to the Known Limitation document.

The message can be safely ignored.

BR

Tal

View solution in original post

(1)
15 Replies
the_rock
Legend
Legend

I had seen similar messages for one customer and when we rebooted the firewall, they went away. I have a feeling reboot clears those files in tmp directory...thats my best educated guess.

Amogha_Chandras
Employee
Employee

This error occurs when there is a shared library missing from the gaia os 

Shared Libraries are libraries that contain code loaded by programs when they start. Missing shared libraries can cause various issues. However, the issue occurs very rarely. 

Best to open a tac ticket, there would be a requirement to copy the library from another machine onto this.

 

The library in this case is  libcpatlas.so

Since it involves directories , best to perform under the guidance of the TAC experts

But the sk to use is sk162393

0 Kudos
Tal_Paz-Fridman
Employee
Employee

Hi,

I've sent a question to the relevant R&D owner. A similar issue was fixed in R81.10 and I'm checking to see if t might apply here or can be added to JHF as well.

Thanks

0 Kudos
burticio
Participant

UPDATE.

 

I checked the steps in sk162393, and I found the library exists in the gateways within the cluster. The library file is in the right directory $FW_DIR/lib/, and this path is set correctly in the LD_LIBRARY_PATH variable. 

 

So I rebooted each member of the cluster. First the standby one. After it rebooted and checked the cluster worked correctly, I tried to install policy to check any changes, and it still showed the alerts. 

I put the recently rebooted GW as active in the cluster, and rebooted the other one. After it rebooted, I checked the cluster was working correctly and installed policy again. The alerts were gone. I made some minor changes in the policy, as labels and logging options in tules, and installed the policy, again with no alerts.

But when I made a change in the objects (It was incorrectly set as internal one interface), and installed policy, the alerts showed again. 

I made other changes in policy and installed it, but the alerts were gone again. 

 

I will keep monitoring if the alerts shows again and in which cases, and if neccesary I will open Support case in TAC. Definitively the reboot made some changes, and it makes sense, as the enviroment variables were set correctly and a reboot should take them.

 

I will keep updatig the case.

Thanks!

Nik_Bloemers
Advisor

Did you have this resolved? I'm running into the same situation on R81 (with jumbo take 51).

0 Kudos
Tal_Paz-Fridman
Employee
Employee

After checking with relevant R&D owners, this is a known issue and was just added to the Known Limitation document.

The message can be safely ignored.

BR

Tal

(1)
Gary_Scott
Contributor

I am seeing this too in a recent upgrade to 81.10 jumbo 66

0 Kudos
SP
Explorer

We just upgraded from 80.40 jumbo 91 to 81.10 jumbo 66 yesterday and same things for us!

0 Kudos
Tal_Paz-Fridman
Employee
Employee

Hi 

Just to update that the issue will be solved in a future JHF (still do not have additional details).

Thanks

Tal

SteveMad
Explorer

Hi, we just updated from 81.10 T45 to T66 and we are having this issue. For us this seems to be impacting VPN connections with remote gateways. Policy seems to be inconsistent - if the central cluster is switched, tunnels are down until policy is pushed again

Regards,
Stefan

0 Kudos
Tal_Paz-Fridman
Employee
Employee

As far as we know the message itself is only only a cosmetic issue and should not impact functionality. As I wrote in a previous post it will be solved in a future JHF.

If you are running into other issues please contact our Support for a deeper investigation.

 

0 Kudos
Nik_Bloemers
Advisor

Still present in the latest take 87. What future jumbo is this planned for? This issue has been reported for 14 months now judging from this topic.

0 Kudos
Jones
Contributor
Contributor

Hi,

I just updated to R81.10 JHF 75, and this non-issue is still there.

Kind Regards,

Jones

0 Kudos
CPRQ
Collaborator

Hi Burticio and Community, We are also planning to cluster upgrade from R80.20 to R81.10. Do you recommend clean install OR in place upgrade. If we do clean install, do we have to set OSPF and static route again after upgrade? Also if possible can you please send the upgrade procedure/steps. Thanks

0 Kudos
Chris_Atkinson
Employee Employee
Employee

Clean install will get you the new XFS file system for the gateway.

For instructions please refer:

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Installation_and_Upgrade_Gui...

CCSM R77/R80/ELITE
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events