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.

Does that only happen for kernel messages or also if you run logger foo?

I think I have only seen malformed log entries in connection with kernel messages, however it's not only kernel messages that are affected. I am getting the impression that rsyslog gets a hickup at some point and then is not able to issue coherent log messages until at some point it gets into step again and then log messages are coherent again (and then at some point they break again etc.).
*t

Tomas Pospisek <tpo_...@sourcepole.ch> schrieb:

Package: rsyslog
Version: 5.8.11-2
Severity: important

On two of our machines we are seeing that rsyslog is filling
up the log with undecipherable gibberish:

From /var/log/kern.log (other logs are also affected such as
*/syslog):

Mar  7 03:29:02 brisi kernel: [236975.910574] EXT3-fs (dm-12): recovery
complete
Mar  7 03:37:06 brisi kernel: 9]X- m2 nnnjn<2596Xfd2mtfseiord
e<6>[237459.93863] ET-s(m1) sn nenljra96]trnepeiufn d12>7.6
3p_a:lnnecie1
  Mar  7 03:37:06 brisi kernel: [492xr_ndirei3
Mar  7 03:41:58 brisi kernel: 39]_nnegfed2>50X 2o st>56X 2c
e<>[237712.63]jrlst.ottaes55E3sd1:ot lyewhrr tme15 ulti m
elsn.34e3p_negfed9 rhnioe eee
  Mar  7 03:45:07 brisi kernel: >3526Xs- eptam

The corresponding output from dmesg:

  [236975.910574] EXT3-fs (dm-12): recovery complete
[236975.984204] EXT3-fs (dm-12): mounted filesystem with ordered data
mode
  [237050.760055] kjournald starting.  Commit interval 5 seconds
  [237050.789205] EXT3-fs (dm-12): using internal journal
[237050.790426] EXT3-fs (dm-12): mounted filesystem with ordered data
mode
  [237459.946661] kjournald starting.  Commit interval 5 seconds
  [237459.953863] EXT3-fs (dm-12): using internal journal
[237459.965601] ext3_orphan_cleanup: deleting unreferenced inode 311354
[237459.966597] ext3_orphan_cleanup: deleting unreferenced inode 311342
[237459.966614] ext3_orphan_cleanup: deleting unreferenced inode 311340
[237459.966621] ext3_orphan_cleanup: deleting unreferenced inode 311338
[237459.967046] ext3_orphan_cleanup: deleting unreferenced inode 311298
  [237459.967056] EXT3-fs (dm-12): 5 orphan inodes deleted
  [237459.967662] EXT3-fs (dm-12): recovery complete
[237460.037427] EXT3-fs (dm-12): mounted filesystem with ordered data
mode
  [237712.565835] kjournald starting.  Commit interval 5 seconds
  [237712.596382] EXT3-fs (dm-12): using internal journal
[237712.596995] EXT3-fs (dm-12): mounted filesystem with ordered data
mode

Note that some of the timestamps in the kern.log and in dmesg
correspond.

One could think that this is a result of the filesystem breaking, but
that
is not the case. The above fsck's are from lvm snapshots that are (in
theory) not interfering with the "real" FS.

Additionaly we are seing the same symptoms (gibberish in the logs) on
another machine that doesn't do fscks on lvm snapshots, that is the
gibberish occursare aparently random times there.

This problem has also been reported to the rsyslog mailing list:
  http://lists.adiscon.net/pipermail/rsyslog/2013-March/031832.html

We have also tested this with rsyslog 7.2.5-1 from experimental (as
seen
inthe ML thread above).

It's weird that this problem hasn't been reported elsewhere yet, since
we're seeing it on two different, independently set up machines.
*t

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to