Mailing List Archive

[Bug 2982] Writing logs to standard output
https://bugs.exim.org/show_bug.cgi?id=2982

--- Comment #5 from ivanov17 <ivanov17@riseup.net> ---
Hello, Jeremy!

It just means that people will continue to create multilog for their Exim
containers using tricks and bad practices because people want to read the logs.
Common practice is to store logs from thousands of containers running on
hundreds of hosts in one database and then filter the multilog with special
tools. Of course, all these containers write very different classes of
information. It probably doesn't make sense, right?

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2982] Writing logs to standard output [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2982

Martin Kealey <from-exim-bugzilla@kurahaupo.gen.nz> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |from-exim-bugzilla@kurahaup
| |o.gen.nz

--- Comment #1 from Martin Kealey <from-exim-bugzilla@kurahaupo.gen.nz> ---
Exim can use syslog, and rsyslogd or syslogngd you can configure the daemons to
match based on the details of the sending process and/or the body of the
message, not just the labelled facility and severity.

Or link with this:

#include <sys/types.h>
#include <unistd.h>
#include <time.h>
#include <syslog.h>
#include <stdio.h>

void openlog(chat *ident, int option, int facility )
{}

void
syslog(int prio, char *msg, ...)
{
struct timespec t;
clock_gettime(CLOCK_REALTIME, &t);
struct tm T;
char tt[20];
strftime(tt, sizeof tt, "%F %T", gmtime_r(t.tv_sec, &T)),
printf("%s.%.4u [%u] ",
tt, t.tv_nsec/100000,
getpid());
va_list v;
va_start(v,msg);
vprintf(m, v);
va_end(v);
}

void closesyslog()
{
fflush(stdout);
}

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2982] Writing logs to standard output [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2982

--- Comment #2 from ivanov17 <ivanov17@riseup.net> ---
Hello, Martin!

Maybe I didn't explain well what's going on.

I am running Exim in an OCI container. This assumes that only the Exim process
will run in the container.

Exim itself works well in a containerized environment. But there is a problem
with logging.

In containerized environments, logs are written to the container's standard
output. Thus, they can be read and collected from outside the container.

Exim doesn't allow logs to be sent to standard output. So I don't have the
ability to read and collect container logs in the normal way.

There is a workaround: we can create symlinks to /dev/stdout and /dev/stderr
instead of log files when creating a container image for Exim. It works, but
it's ugly.

Or we can run multiple processes in the same container. This is possible, but
requires process management via an entrypoint script. It is ugly and breaks
security standards.

Unfortunately, Exim cannot send log data to syslog daemon over tcp. If it were
possible, I could use another container running the syslog daemon. It would be
inconvenient, but better than running multiple processes in the same container.

In summary, the problem with Exim logging in containerized environments can
only be completely solved if Exim itself starts sending logs to standard
output.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2982] Writing logs to standard output [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2982

--- Comment #3 from Martin Kealey <from-exim-bugzilla@kurahaupo.gen.nz> ---
"syslog over UDP is unreliable" is one of those things that while technically
true, us rarely a real problem.

Loss of UDP packets is caused by two factors: the underlying transport dropping
oackets, and the receiver's packet queue (in the kernel) overrunning.

Sending between containers within one host has 100% reliable transport -
otherwise you have a kernel bug - and the only things that could stall syslogd
enough to cause overruns would be IO bandwidth saturation and delayed process
scheduling, both of which are manageable.

The log messages are a tiny fraction of the size of the messages that are being
transported, so in practice this risk is tolerable for many.

If your use case cannot tolerate even a one-in-a-million loss of log messages,
then you would want to use the syslog-to-stdout module that I posted before.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2982] Writing logs to standard output [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2982

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|NEW |RESOLVED

--- Comment #4 from Jeremy Harris <jgh146exb@wizmail.org> ---
Exim writes several different classes of information to different files,
when logging to files. Mixing them all to stdout would not make sense.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##