(Cc:ing Debian's lxc maintainer)
On Mon, 27 May 2013, Florian Ernst wrote:
On Thu, Mar 07, 2013 at 01:07:38PM +0100, Tomas Pospisek wrote:
On Thu, 7 Mar 2013, Michael Biebl wrote:
Is that on virtualised hardware?
No, that's on the metal. However each lxc container is *also*
running out of the box rsyslog (without any config adaptations), so
it might be that there's a problem there somewhere with all those
rsyslogs getting along. However of course each syslog is sitting on
its own FS and thus on its own log files.
Ad hoc I couldn't tell what access rights those lxc containers have
wrt to the kernel log feed and how that feed works.
FWIW, I experienced the same messed-up logs some time ago when running
rsyslog in an LXC guest. I circumvented that by disabling kernel logging
support in the guest as follows:
diff --git a/rsyslog.conf b/rsyslog.conf
index 2a7f9f9..94fff07 100644
--- a/rsyslog.conf
+++ b/rsyslog.conf
@@ -9,7 +9,7 @@
#################
$ModLoad imuxsock # provides support for local system logging
-$ModLoad imklog # provides kernel logging support (previously done by rklogd)
+#$ModLoad imklog # provides kernel logging support (previously done by
rklogd)
#$ModLoad immark # provides --MARK-- message capability
# provides UDP syslog reception
I am not sure what to do about this bug report.
The basic problem at hand here is that it seems that reading from the
kernel log facility is *destructive*, so when multiple processes, no
matter if inside a lxc container or on the host system read from the
kernel log facility, then there's a race condition on the logs coming
from the kernel log facility with an undefined outcome on who will get
what data from the kernel log facility.
The result is gibberish in kern.log.
A solution to this problem is to disable reading from the kernel log
facility inside the guest VMs.
Optimally this condition would be detected automatically by the VM guests
which would automatically disable reading from the kernel log facility
once they detect they are a VM.
Or we leave it as is and hope that the sysadmin is kowledgeable enough to
disable it manually.
What to do?
?
*t
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
