Mohd Husaam Mehdi 9e69ed7bc0 logmngr: use separate fluent-bit instances for main and user conf ... So the philosophy here is that there will be one main fluent-bit instance, which will read from /dev/kmsg and /dev/log and write to /var/log/messages. This is done to reduce the chance of introducing errors in config and making sure that var/log/messages is always populated because logread depends on it. For example, an unavailable URL for a udp based syslog output plugin can cause fluent-bit to exit entirely. The other fluent-bit instance uses a different "user" config file. Which will handle log_file, log_remote and included configs. It has a single hard coded input tail plugin which reads from /var/log/messages. Any filter that is applied will act on the main config and thus, only filtered logs will be available to both fluent-bit instances.		2026-01-22 21:20:24 +05:30
..
config	logmngr: show facility and severity in logs	2025-12-29 14:30:05 +05:30
fluent-bit	logmngr: show facility and severity in logs	2025-12-29 14:30:05 +05:30
hotplug.d/ntp	logmngr: reload fluent-bit on ntp sync event (via hotplug)	2025-12-04 19:41:25 +05:30
init.d	logmngr: prepone to start before most of the apps	2025-11-18 12:50:04 +05:30
uci-defaults	logmngr: use separate fluent-bit instances for main and user conf	2026-01-22 21:20:24 +05:30