Bug ID 651681: Orphaned bigd instances may exist (within multi-process bigd)

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP TMOS(all modules)

Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1

Fixed In:

Opened: Mar 15, 2017
Severity: 3-Major
Related Article:


When multi-process 'bigd' is configured, orphaned 'bigd' instances may be exit; such as an orphaned 'bigd.1' alongside the active 'bigd.1'.


The suspended 'bigd' process consumes process memory. The process might be suspended (consuming no CPU resources), or running, which might result in "double-monitoring" the resources assigned to that 'bigd' process. Note: If double-monitoring occurs, monitor status should be correct, but the double-monitoring unnecessarily consumes extra resources.


-- db variable Bigd.NumProcs to 2 or higher. -- System monitors with long timeouts (such as ~183 seconds or longer), might also be relevant. When 'bigd' manages monitor configurations that results in no monitoring activity for a long time (such as due to long monitor timeouts), the operating system may temporarily suspend (and later resume) the 'bigd' process. The system might treat the 'bigd' process as if it were "hung", and start another 'bigd' instance without explicitly terminating the suspended 'bigd' process.


Configure 'bigd' to run as a single process. To do so, set the db variable Bigd.NumProcs to 1. Shortening monitor timeouts can reduce the possibility of a 'bigd' process being (temporarily) suspended by the operating system.

Fix Information

Multi-process 'bigd' no longer produces orphaned (suspended) process instances.

Behavior Change