Hi, First of all, sorry in advance if the beginning of this post looks more like a bug report discussion than a debian-devel post. > try this instead: > > $ journalctl _SYSTEMD_UNIT=systemd-journald.service > > which will (most likely) also show messages like "Suppressed 1927 messages > from /PATH/FOO.slice". You can then use > > $ journalctl _SYSTEMD_SLICE=FOO.slice > > to display the non-suppressed part of the spew that's responsible > for this overrun. (intentional disabling of word-wrapping just for the few lines of logs) raph@arche:~$ journalctl _SYSTEMD_UNIT=systemd-journald.service -- Logs begin at lun. 2014-11-10 20:14:11 CET, end at lun. 2014-11-17 23:31:22 CET. -- nov. 10 20:14:11 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 784.0M available → current limit 79.2M). nov. 10 20:14:11 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 784.0M available → current limit 79.2M). nov. 10 20:14:11 arche systemd-journal[207]: Journal started nov. 10 20:14:19 arche systemd-journal[207]: Runtime journal is using 8.0M (max allowed 79.2M, trying to leave 118.8M free of 783.3M available → current limit 79.2M). nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed 42 messages. nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed 1 messages. nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed 2 messages. nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed 2 messages. nov. 15 18:22:24 arche systemd-journal[207]: Forwarding to syslog missed 9 messages. nov. 15 18:22:54 arche systemd-journal[207]: Forwarding to syslog missed 3 messages. nov. 16 22:27:37 arche systemd-journal[207]: Forwarding to syslog missed 1 messages. nov. 16 22:28:13 arche systemd-journal[207]: Forwarding to syslog missed 1 messages. nov. 17 15:13:45 arche systemd-journal[207]: Forwarding to syslog missed 18 messages. As you can see, no syslog-filler slice to investigate in particular. I'm quite happy though, because after you and Ben emitted the idea that I may have ran with messed up logs long before I upgraded to systemd, I was quite worried, even if it's a sid desktop that I moderately care about (after all, if that's the case, it could happen on my production servers as well); but the small number of missed messages (less than 50, very different from the thousands you suspected) make me think that my logs on this machine are a lot less likely to have been crippled for a long time without my knowledge than both of you initially thought, aren't they ? >> drop the message" (IIRC it was even more condescending, like "we don't >> have to wait for this" or something). Really ? The very piece of code >> which is supposed to talk to syslog... doesn't wait for syslog ? >> > Do you want to buffer an unbounded number of messages in RAM instead, > hoping that syslog will catch up eventually? Thanks, but no thanks. > (Implementing a _bounded_ message buffer in systemd doesn't make sense, > because you can get the exact same effect by simply doing (a), above.) Now for the interesting part (for debian-devel, anyway :) ). Maybe as a sysadmin I lack some C arcane knowledge and it may sound like a silly question to you, but why would that be such a bad idea ? Rsyslog (debian default since lenny) does this; if it's configured to send messages to a remote server via TCP, and if the server is unreachable for whatever reason, it stores the messages in a buffer until they can be sent; it even stores them to the disk if the case it's terminated. Why journald using some more KB or MB of RAM to store the messages it couldn't forward in time, and waiting for syslog to catch up, would be such a bad thing to do ? > It's likely (though not certain) that your logs have been crippled in the > past, albeit in a different way, and you simply didn't notice because the > logging program didn't tell you. The standard syslog(3) code doesn't. Like I said, it doesn't look that way (at least I hope it doesn't) but correct me if I'm wrong. Regards, -- Raphaël Halimi
Attachment:
signature.asc
Description: OpenPGP digital signature