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

[Thomas_Eichelbu]

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?

Uninstalling Take 139 gets it running again...

[Chris_Atkinson]

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

[Thomas_Eichelbu]

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... 

[Chris_Atkinson]

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?

[Bob_Zimmerman]

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.

[Chris_Atkinson]

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

[Timothy_Hall]

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.

[Thomas_Eichelbu]

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.

[Timothy_Hall]

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...

[Timothy_Hall]

@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.

[Thomas_Eichelbu]

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!

[the_rock]

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.

[kwo · Accepted solution]

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.

[Bernhard]

This also works for me!

Thanks!

[Thomas_Eichelbu]

Awesome!

[the_rock]

Excellent find, thanks for sharing!!

[Bob_Zimmerman]

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.

[Bernhard]

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

[Phil_Pasquier]

Awesome guys, you saved our weekend !

[Bernhard]

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

[Chris_Atkinson · Accepted solution]

Ongoing JHF T154 for R80.40 addresses the above.