The config plumbing itself provides an error message. The one given here
was also totally wrong ;-)
Thanks to Frank Bicknell for spotting this message and making me alert.
this also requires changes to some tooling.
Also, when assigning a dynamic port in tcpserver, the same port
number is used for IPv4 and IPv6.
Also removing some left-over debug output.
closes https://github.com/rsyslog/rsyslog/issues/2987
Restart the program if it does not respond within timeout.
New setting 'confirmTimeout' (default 10 seconds).
Allow the program to provide keep-alive feedback when a
message requires long-running processing.
Improve efficiency when reading feedback line (use buffer).
Retry interrupted writes/reads to/from pipe.
New setting 'reportFailures' for reporting error messages
from the program.
Report child termination when writing to pipe.
Minor refactor: renamed writePipe function to sendMessage,
renamed readPipe to readStatus.
to wait for process startup, the rsyslog startup calles were (ab)used. This
caused issues whenever they were updated to new rsyslog needs. Now a dedicated
"API" for process startup has been added and the tests been modified to use it.
Capture program output using a pipe shared with all child processes,
and write to the file using a dedicated thread. Ensures lines emitted
by the child processes will not be intermingled in the output file if
the lines are less than PIPE_BUF chars long and are written in line-
buffered mode.
Reopen output file on HUP, to support external rotation of the file.
New setting 'fileCreateMode' as in omfile.
With these improvements the 'output' setting should now be usable for
production (it was originally intended only for debugging).
Redirect stdout/stderr of child process to /dev/null when not captured.
Closes#2787
Minor: simplify some test code: 'wait-startup' not needed after
'startup', 'wait-queueempty' not needed before 'shutdown_when_empty'.
The RSYSLOG_DYNNAME used to make test file unique was very long,
which potentially causes issues with some test scenarios.
see also: https://github.com/rsyslog/rsyslog/pull/2945#issuecomment-417078768
Also, the dynamic port determination method we currently use
is not 100% reliable. That port number was used inside the DYNNAME
and thus was not necessarily unique. This has now changed to the
current time in microseconds plus a hash of the test file name. This
should be sufficiently unique. If still not, we can now simply
extend the test_id program (e.g. read /dev/urandom).
Until now when port 0 was specified in imtcp, imgssapi or imdiag,
it was automatically changed to 514 in tcpsrv.
Imtcp and imgssapi accept port 0, but only if parameter listenPortFileName
(imgssapi: inputgsslistenportfilename) is specified. Otherwise it will
still change the port.
Imdiag always accepts 0 as a port and will create a socket with a random
port.
This file is referenced inside IBM's AIX configure.ac code but
cannot be found inside the source. I found it mentioned in some
mail an added it to the source of the project tree.
I do *NOT* know if the content or location is correct nor am
I able to verify if the build succeeds or not.
see also: https://github.com/rsyslog/rsyslog/issues/2597
