3

I am using rsyslog on Debian Buster.

I am using old-style sysvinit, not systemd. rsyslog is started late in the init startup sequence, after most init scripts have run.

The dmesg messages during boot process and other early log messages from other startup scripts that ran before rsyslog was started, are not lost. rsyslog will log them immediately when it starts.

Where were these messages stored, when rsyslog was not running ?

Can I clear this "cache" before I start rsyslog, so that the early boot message are not logged ?

Or, even better, can I filter them out, so that they are logged into main syslog file:

*.*    -/var/log/syslog

but not logged into another:

*.*    |/dev/xconsole

UPDATE AND CLARIFICATION

I realized it might not be entirely clear what problem I am trying to solve. So here is some clarification of the situation:

In addition to standard syslog logging (ie, /var/log/syslog), I am also logging the same info to /dev/xconsole, and when I am logged in my desktop session as user, I have terminal on background with following command:

cat /dev/xconsole

that way, I can immediately see new logs appearing in my background. Also, unlike regular file, /dev/xconsole is emptied after it has been read. So when i log out, and log back in again, I don't see old messages, but only new ones.

Now, the problem is that after boot, there is so much logs in the kernel buffer, that when rsyslog starts, it fills up the whole capacity of /dev/xconsole with useless debugging early boot info.

And I am mostly interested in the late stage boot messages, and these are missing. Only after I cat /dev/xconsole for the first time, do I free up the space, and new messages can come.

I added this ugly hack in /etc/rsyslog.conf:

:msg, startswith, "\[    "              stop
*.*    |/dev/xconsole

This basically discards all early messages that start with single digit second counter [ 0.000000], but accept all later messages, ie [ 14.348189]

This works, but I consider it dirty workaround.

So, how can I get rid of the early boot messages that I am not interested in, and log the useful init boot script messages?

  • 3
    The kernel maintains a ring buffer for early log messages. rsyslog drains and resets the ring buffer. What's your use case for ignoring early log messages? On the face of it sounds like something that will bite you later. – waltinator Aug 29 at 17:27
  • @waltinator - thank you. I have updated my question, and added clarification of the problem. – 400 the Cat Aug 30 at 5:49
  • Unless it's precisely what you mean (and I don't think so) you should not use EARLY in that context. (Title & Bold phrase at the end) "Early boot messages" commonly refer to messages that are echoed before the console code is initialized. Not before whatever syslog starts running (which happens considerably after) The recording of those actually "early boot messages" is controlled by the CONFIG_EARLY_PRINTK kernel config option. – MC68020 Sep 1 at 11:46
2
+75

The syslog process typically picks up messages from three sources:

  1. Applications, via /dev/log
  2. Network via port 514
  3. The kernel, via /proc/kmsg

Now the first... traditionally any application that sends to /dev/log before a syslogd process starts will have their messages lost. systemd confuses things a little because it can listen on that socket instead. And then syslogd can read from systemd. But this doesn't appear to be your concern.

The second is clearly not relevant to your question.

So we focus on the third. These are the lines that begin with [...], where the number is a timestamp from after boot. These are messages created by the kernel, and not user space applications.

Kernel messages are put into a "ring buffer", and when rsyslog starts it will read this buffer to put the data... wherever the config files say put it.

Under normal circumstances this is good. You want a log of all the kernel boot messages, just in case something doesn't start properly.

But if you don't care about them then you can use the command dmesg --clear. That clears the "ring buffer". So if you put that in the boot sequence before you start rsyslog then the daemon will not read any kernel messages; the buffer has been cleared.

Now how you do that is very dependent on the distribution you're running. With traditional sysvinit you might want to create a RC file that runs just before the syslog start script. With systemd you might want to create a unit with a prereq on the syslog process.

| improve this answer | |
  • dmesg --clear does not help. It clears the log as shown by dmesg, but not what is logged via rsyslog. – 400 the Cat Sep 1 at 12:29
  • You have to run it before you start syslogd so the ring buffer is empty – Stephen Harris Sep 1 at 19:11
  • as I said: IT DOES NOT WORK. I have started system without rsyslog, cleared ring buffer, then started rsyslog. but still I get these early boot messages in rsyslog. The only thing that was cleared was the log shown by dmesg command. Did you actually test it on your side ? Or are you just defending your idea how you imagine it should work ? – 400 the Cat Sep 2 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.