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

2200 Appliance R80.40 and Take 139, CPD stopps.

Hello Check Mates, 

yes sure the 2200 is legacy hardware but still in support until June 2022.
Therefor some customers have it in use still today.

Installing R80.40 with Take 139 on a 2200 appliance causes CPD to fail ...
i tried a few installation runs on 2200 hardware ... always the same result ...
best advice would be, get rid of that old devices but they are still in use.

Check Mates have you seen this before?

 

cpwd_admin.PNG

Uninstalling Take 139 gets it running again...

0 Kudos
2 Solutions

Accepted Solutions
kwo
Participant

I have this problem too and reproducible since T126 were it first occurred. It's still there with T139. I already have a TAC call open since this time, but unfortunately still no official solution. Still in progress, since months somewhat unbelievable...

During my tests I found the root cause is a file /etc/hw_info/sensors.xml which is created with zero bytes after the Jumbo T126 and higher install. This will cause the cpd to crash. Up to T125 this file did not even exist.

simple (temporary) fix for me:

After upgrade delete the file /etc/hw_info/sensors.xml via logging in via SSH and after some time CPD comes up again started by the watchdog or simply do a reboot.

 

 

View solution in original post

(1)
Chris_Atkinson
Employee Employee
Employee

Ongoing JHF T154 for R80.40 addresses the above.

CCSM R77/R80/ELITE

View solution in original post

0 Kudos
20 Replies
Chris_Atkinson
Employee Employee
Employee

Relevance is yet to be determined but is this a 2200 or a 2200B the difference is the amount of RAM?

CCSM R77/R80/ELITE
0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Well thats a good point!

I was also thinking on that possibility that system resources were depleted.
the models i have,  have 2GB of memory ... 
Do the other models come with 4GB of memory? 
I also tried to update the memory. I slaughtered all my old notebooks at home but i had no compatible memory modules available ... so iam stuck with 2GB ram models here... 

0 Kudos
Chris_Atkinson
Employee Employee
Employee

4GB RAM came in the B-variant.

Was also offered as an upgrade kit using SKU: CPAC-RAM2GB-2200 in the past (before End of sale).

What does your box report about its resource usage i.e. free memory etc?

CCSM R77/R80/ELITE
0 Kudos
Bob_Zimmerman
Authority
Authority

The 2200 takes normal DDR3 (dmidecode mistakenly claims it's DDR2). It can use up to 8 GB. I have one as an R81 standalone right now for API testing. I definitely wouldn't recommend it for production use, though. It only has an Atom D525.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

To echo this R81 isn't supported on 2012 series appliances and earlier, even if you are able to get it to work.

 

CCSM R77/R80/ELITE
0 Kudos
Timothy_Hall
Legend Legend
Legend

Minimum memory requirement for a security gateway under R80.40 is 4GB so if you have a 2GB 2200 instead of a 4GB 2200B that will definitely be a no go even if it sort of works.  Possible that the Jumbo HFA introduced some memory hungry elements such that 4GB is not enough either.  Please post output of free -m.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Hello, yes understood,
just received the info from costumer, the firewalls are a 4GB variant ...

free -h

              total        used        free      shared  buff/cache   available

Mem:           3.6G        1.4G        581M        4.1M        1.6G        1.7G

Swap:          4.0G         83M        3.9G

so even with 4GB the CPD crashed.
next step would be a TAC case then.

0 Kudos
Timothy_Hall
Legend Legend
Legend

You could try poking around in $CPDIR/log/cpd.elg as cpd might be barfing some kind of error message into there when it is being restarted by cpwd and subsequently crashes.  You could also try to manually start cpd under debugging with the -d option if it can't even get off the ground far enough to write anything into $CPDIR/log/cpd.elg.

TAC will probably ask for all this anyway...there seems to be enough free memory for cpd to run...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Timothy_Hall
Legend Legend
Legend

@the_rock's post about having to do a fresh reload just jarred my memory about a recent issue a customer of mine had that is similar.  The situation was they did not have firewall log rotation set, so their SMS ran itself out of disk space in the /var/log partition.  Once disk space was cleared cpd would start but just sit there consuming huge amounts of CPU until it eventually died on its own.

The disk overflow caused corruption in the CPEPS database which was crashing the cpd daemon, so we cleared it as described in these two SKs: sk101484: CPD is consuming high CPU utilization (>90%) or CPD is terminated on the Security Gateway & sk168674: CPD process consumes CPU at high level on Security Gateway Perhaps this database got corrupt somehow due to a transient resource shortage on your 2200.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Hello regarding, sk101484
i see many of this logs:

[cpWatchDog 4361 4135581440]@XXXXXXX[1 Feb 13:55:26] [ERROR] Process CPD terminated abnormally : Unhandled signal 11 (SIGSEGV). Core dumped.


but none of this logs:

[ERROR] Failed to register new process file_name:CPD_XXX_XXX.mntr


i try to run the solution described in sk101484 asap!

0 Kudos
the_rock
Legend
Legend

I had seen this problem before and ONLY solution that worked after many hours of trying was to do fresh install and that fixed the problem. Though, reading your post, sounds to me like that was done already...if so, then I really cant suggest anything else, sorry. I see guys are referencing more RAM and that may help in your situation.

0 Kudos
kwo
Participant

I have this problem too and reproducible since T126 were it first occurred. It's still there with T139. I already have a TAC call open since this time, but unfortunately still no official solution. Still in progress, since months somewhat unbelievable...

During my tests I found the root cause is a file /etc/hw_info/sensors.xml which is created with zero bytes after the Jumbo T126 and higher install. This will cause the cpd to crash. Up to T125 this file did not even exist.

simple (temporary) fix for me:

After upgrade delete the file /etc/hw_info/sensors.xml via logging in via SSH and after some time CPD comes up again started by the watchdog or simply do a reboot.

 

 

(1)
Bernhard
Participant

This also works for me!

Thanks!

0 Kudos
Thomas_Eichelbu
Advisor
Advisor

Awesome!

0 Kudos
the_rock
Legend
Legend

Excellent find, thanks for sharing!!

0 Kudos
Bob_Zimmerman
Authority
Authority

cpd was also failing on one of my 2200 units running R81 jumbo 51. I hadn't had time to dig into what was wrong. Removing the mentioned file got it working, too.

0 Kudos
Bernhard
Participant

RnD is already aware of the issue and are working on it. 

0 Kudos
Phil_Pasquier
Explorer

Awesome guys, you saved our weekend !

0 Kudos
Bernhard
Participant

Issue is listed in PRJ-36728 and fix will be included in next JHF

0 Kudos
Chris_Atkinson
Employee Employee
Employee

Ongoing JHF T154 for R80.40 addresses the above.

CCSM R77/R80/ELITE
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events