On 23.03.2025 10:02, Alexey Rudenko-Desnyak via rsyslog wrote:
BINARY. Binary /tmp/test.php simply adds stdin input to "out.log" line by
line:
===
#!/usr/bin/php
<?php
$SyslogMessage = fgets(STDIN, 0x1000);
file_put_contents('/tmp/out.log', $SyslogMessage, FILE_APPEND);
Wait a second. Is it your php code?It is supposed to read a single line from the input, write it to the file and then exit. So omprog will re-spawn when it notices it stopped but it doesn't mean that there will not be data in the buffer lost when the program is restarted. I won't even get into the fact that this is an atrociously ineffective way of doing this - spawn a new process for each event? No way. You should have a process waiting for input and writing the input as it arrives. But even then the way to go would be to use confirmMessages setting and queueing - otherwise the events still could be lost if they got queued into an out pipe and not properly processed by the program.
You can test it for yourself. While this: for A in `seq 10`; do echo -n 1 $A\\n2 $A; donewill give you 20 lines of output, if you do the same but spawn your php code for each two lines of input
for A in `seq 10`; do echo -n 1 $A\\n2 $A | /tmp/test.php; done You will get only the first lines into your file. So it's not omprog "losing" messages. It's working exactly as designed.The old-style execute action worked completely differently - it spawned a separate process for every message. It was by design.
Cheers, MK _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
