Bug ID 471901: Log publishers with failed HSL destinations continue to accept and deliver logs.

Last Modified: Oct 06, 2020

Bug Tracker

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

Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9

Fixed In:

Opened: Jul 16, 2014
Severity: 3-Major
Related AskF5 Article:


Log publishers with failed HSL destinations continue to accept and deliver logs to other destinations.


Customers may falsely believe either that publishers are /supposed/ to ignore failures, or that failed destinations are actually working.


Log publishers normally only accept logs if all associated destinations report being up. On systems with this bug, as long as an HSL destination can be configured and initialized (i.e. as long as there is a route to the destination), it is believed to be "up" even if actual connections cannot be established.


Upgrade. There is no work-around for this problem without picking up new code.

Fix Information

After this fix, the logging library will properly detect failed HSL destinations for log sources in the TMM and in V2 Plugins. Logs sourced by V1 Plugins and stand-alone userland daemons will still be published even if their associated HSL destinations are down. This latter problem has not yet been fixed in any release.

Behavior Change