program()destinations ? e.g. fork multiple copies thereof ?
programwould be spawned, and messages load-balanced among them
My assumption is, that someone probably want to keep sending messages via other processes, while one of them is blocked. (Not viable using round-robin balancing.)
(In the meantime: My earlier statement was incorrect, acknowledgement was not an issue in case of program destinations, since syslog-ng consider the message acknowledged if the write on the pipe was successfull.)
HOST, with a limit of
If I understand it correctly, the
inotifywait -m -r -e close_writescript of yours will remove the file right after a process writing that file closes its fd.
Fortunately, when syslog-ng opens a file for reading, it keeps that file open. This means that if the file is deleted before it is fully processed by syslog-ng, we can still finish reading the file (The file will not really be deleted until the last FD is closed).
The only problematic scenario is when a file is deleted, but syslog-ng has not yet been able to open the file in that amount of time.
I think this is the case when you get the message you mentioned: Follow-mode file source not found
wildcard-file()source monitors files continuously, we don't close those files after processing them, so I think you either have to add a few-second delay before removing the file (in the hope syslog-ng can open it), or you should choose a different approach (a simple delay does not guarantee anything, but monitoring syslog-ng statistics (
syslog-ng-ctl stats), or searching for internal debug logs that state we opened the file might actually work)
What I finally understand from your reply that my script is not going to work.
Adding a few-second delay might work, but it's an ugly hack, and nothing is guaranteed.
The better option (until we implement #3695) would be something that relies on the statistics of syslog-ng.
For example, it is possible to write a script that periodically checks the output of the
sbin/syslog-ng-ctl query get 'src.file.*.processed' command, and removes the file only when the processed counter of the file can be found in the list, and it is greater than 0.
This should work reliably only if you do NOT re-create the same file (path) after deleting it (syslog-ng file statistics are not reset after the file is removed).
The fallback flag is for processing messages that are not processed by any other normal log paths. You can not mark
log_net as an "invisible" destination, but I'm pretty sure we can refactor/rephrase your configuration to achieve what you want; for example, using
if-else blocks, or embedded log paths,
final flags, or just
Can you share all of your log paths, where
s_sys is used? Exactly what messages would you like to see arrive into