Last Modified: Nov 07, 2022
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
Opened: Jul 16, 2014 Severity: 3-Major Related Article:
Related Article: K81980416
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.
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.