With the change in ubuntu-latest at GitHub, the behavior of the classic
tree command has changed too. Just ignore any return code, the output
is merely for our viewing pleasure -- ocular inspection.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
(-T) -- fixes changes in 8f8332885 that resulted in "Jan 0 00:00:00" timestamps.
check_timestamp() saw the nonzero timestamp.usec and returned without setting
buffer->timestamp, leaving it with nonzero usecs and an all-zeros struct tm.
Slight differences in output when called with `-v` flag:
- Should output to stdout, that's what people expect (not an error)
- Should output *project* name and version, for syslogd this is not
so obvious since it *logs* 'syslogd vx.y.z' while the version is
'sysklogd vx.y.z'
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When logging to a file we want a space to separate proc[pid]: from the
message, but for regular logging local/remote we don't want to inject
an extra space.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This may cause a bit of a regression for some users, but the RFC is
crystal clear on this point, the tag MUST NOT exceed 32 characters.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This is the first RFC5424 (only) support for for logging to a remote
host. The syntax continues to follow the FreeBSD logger.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
As reported on GitHub. When logging to a remote host, after a few
SIGHUP's we get the following log message:
Only 16 IP addresses per socket supported.
When closing all currently open sockets, the socket count must be reset
to allow for opening new ones, otherwise we'll run out of "counts".
Yes, this should be refactored to use the FreeBSD model implementation.
Problem introduced in v2.4.0, commit 075815e.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
No need to advertise that sysklogd is not kept up-to-date in all the
distros on the planet. Nothing much I can do about it.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Do not corrupt logfiles when kernel messages contain control codes,
notably \n. Instead, preserve the kernel's protective C-style hex
encoding. For example, \n embedded in a message by a kernel-level
facility is received as "\x0a". Kernel-level facilities cannot be
trusted to use only syslog-safe codes in kernel messages. See:
<https://kernel.org/doc/Documentation/ABI/testing/dev-kmsg>
This change avoids the possibility of advancing past the null
terminator, by always testing the value at the pointer before
advancing the pointer.
While repairing this, I reconciled the code sections that read the
priority, sequence, and timestamp, so that they handle the pointer in
exactly the same way. This makes the source easier to maintain.
