Last Modified: Jul 10, 2026
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 15.1.10.5, 15.1.10.6, 15.1.10.7, 15.1.10.8, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 16.1.5.1, 16.1.5.2, 16.1.6, 16.1.6.1, 17.0.0, 17.0.0.1, 17.0.0.2, 17.1.0, 17.1.0.1, 17.1.0.2, 17.1.0.3, 17.1.1, 17.1.1.1, 17.1.1.2, 17.1.1.3, 17.1.1.4, 17.1.2, 17.1.2.1, 17.1.2.2, 17.1.3, 17.1.3.1, 17.1.3.2
Opened: Jan 19, 2024 Severity: 3-Major
When DBDaemon logs Java exceptions (for example, DB connection/auth/listener failures), the log entries usually do not include enough object context (monitor, pool member, or key details) to identify which configuration object failed
Administrators and support teams cannot quickly identify errors related to the affected monitor or pool member. This results in delays for remediation and often requires debug logging to be enabled in production environments
- BIG-IP with database monitors in use (mssql, mysql, oracle, postgresql) - Default DBDaemon logging level (debug = no) - Any runtime DB monitor failure that throws/catches exceptions in DBDaemon paths (such as DB_Pinger, MonitorWorker)
- Enable DBDaemon debug logging (globally or per monitor where possible) to capture additional context - Correlate timestamps/thread IDs in /var/log/DBDaemon-*.log with monitor activity - Manually validate monitor credentials/connect strings on likely affected objects
None