Relation between mcpd and linux

mcpd is one of several F5 daemons/processes that run on the linux host to make up TMOS. The mcpd process handles configuration information and communication between TMM (the primary F5 process that does all the traffic processing) and the rest of the processes on the system. The following article describes all the daemons/processes running on a BIG-IP system. It includes F5 developed TMOS processes such as sod, bigd, mcpd, and TMM as well as 3rd party processes such as alertd and httpd:

 

K05645522: BIG-IP daemons (13.x)

 

Doing an AskF5 Search with keywords "mcpd" and "uptime" and the article filter of "Known Issue" resulted in the following KI article that applies to 12.0.0 and 11.x:

 

K39500465: Displaying virtual server statistics may cause an mcpd process memory leak

 

You can search just for "uptime" with the "Known Issue" filter to see all the uptime related bugs.

 

mcpd is one of several F5 daemons/processes that run on the linux host to make up TMOS. The mcpd process handles configuration information and communication between TMM (the primary F5 process that does all the traffic processing) and the rest of the processes on the system. The following article describes all the daemons/processes running on a BIG-IP system. It includes F5 developed TMOS processes such as sod, bigd, mcpd, and TMM as well as 3rd party processes such as alertd and httpd:

 

K05645522: BIG-IP daemons (13.x)

 

Doing an AskF5 Search with keywords "mcpd" and "uptime" and the article filter of "Known Issue" resulted in the following KI article that applies to 12.0.0 and 11.x:

 

K39500465: Displaying virtual server statistics may cause an mcpd process memory leak

 

You can search just for "uptime" with the "Known Issue" filter to see all the uptime related bugs.

 

That's an interesting debate. How often should I reboot my devices. The best rule of thumb I can provide is reboot

 

1. When you make a change to the startup process. After all you want to make sure it comes back up cleanly right?
2. Just before patching. You want to know whether the patching broke it, or it was broken before if it does break. So a sanity reboot is always good here.

Given you should be patching regularly, I'd hesitate to say you're a good netizen for any device having an uptime of years nowadays (Despite the fact that if you search you can probably find me extolling AIX uptimes of >400 days in the past :) ). They may be able to run that way, but you might want to examine the vulnerabilities that are present on a 5 yo OS...

 

We went through a bad batch of hardware many years back too... They'd break on power up. So the answer was to have the network guys in the DC hit reset on the ACTIVE unit on a scheduled basis. Full CHG process, but it certainly weeded out the bad HW... And you had a lot more confidence that in the event of a power loss in the DC (That does happen) you could be more certain that your hardware would come back up