How to prevent logback from outputting its own status at the start of every log when using a layout

Question

This seems like a carelessness error, but I can't seem to find the cause. Logging with logback/slf4j (most recent version slf4j-api-1.6.1, logback core/classic 0.9.24). Simplest log configuration for testing is:

<configuration>
 <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
  <layout class="ch.qos.logback.classic.PatternLayout">
   <!-- DONT USE THIS FORMATTER FOR LIVE LOGGING THE %L LINE NUMBER OUTPUTTER IS SLOW -->
   <pattern>%le %-1r [%c{1}:%L] %m%n</pattern>
  </layout>
 </appender>
 <root level="DEBUG">
  <appender-ref ref="stdout" />
 </root>
</configuration>

Every log setup starts with logback's internal status lines:

11:21:27,825 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
11:21:27,826 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:.../logback-test.xml]
11:21:28,116 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
11:21:28,124 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
11:21:28,129 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [stdout]
11:21:28,180 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [layout] on top of the object stack.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:21:28,206 |-WARN in ch.qos.logback.core.ConsoleAppender[stdout] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:21:28,207 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
11:21:28,207 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [stdout] to Logger[ROOT]

which is, according to the docs, the format logback uses for default. It then finishes reading the config (which is set up to output a different format) and continues with the properly formatted output. There's a config parameter <configuration debug="false"> which does not affect this.

Anyone know how to shut this off?

Recent versions of logback are much faster at calculating %L. — Thorbjørn Ravn Andersen, Nov 01 '16 at 20:32
@ThorbjørnRavnAndersen the docs say "L / line : Generating the line number information is not particularly fast. Thus, its use should be avoided unless execution speed is not an issue." FWIW: http://logback.qos.ch/manual/layouts.html (so maybe it's faster but still not super fast or something...) — rogerdpack, Dec 23 '19 at 15:22
@rogerdpack yes. It is found by analyzing a stack trace of an exception. That has become faster. — Thorbjørn Ravn Andersen, Dec 23 '19 at 21:27

score 295 · Answer 1 · edited Aug 09 '17 at 20:02

295

If you set the debug attribute of the configuration element to true, you will get all status information to the console. If this is your problem, just set it to false or remove it.

If you have any configuration problems of level WARN or above, you will also get all status information logged to the console (including messages of level INFO). The best solution to this problem is to fix the problem (in your case replace the <layout> element with an <encoder> element).

If you for some reason cannot fix the problem, but want to remove the status-information from the console, you can instead configure an alternative StatusListener. Use the NopStatusListener to completely remove the status-information:

<configuration>
  <statusListener class="ch.qos.logback.core.status.NopStatusListener" />
  <!-- etc -->
</configuration>

edited Aug 09 '17 at 20:02

approxiblue

6,982
16
51
59

answered Oct 09 '13 at 10:43

Rasmus Faber

48,631
24
141
189

4

This worked. I wasn't entire clear that the `INFO` log messages would disappear, too, but in fact they do. I know the answer says this, but for some reason it wasn't clear to me. To be oh-so-clear: fix the encoder/layout problem and not only will the warning messages go away, but the info messages will go away, too, even though they are unrelated to the problem. – Jason Nov 22 '15 at 01:34
4

Did not work with the debug attribute, but worked flawlessy with the status listener. – Ameba Spugnosa Jun 23 '16 at 13:08
3

Careful using this approach, it appears to work but it hides the fact that you have a configuration error in your file. The real problem is the WARN logs, these issues should be fixed in config, then all the logs inc. INFO go away. – teknopaul Nov 23 '17 at 11:36
Definitely `status listener` is the way to go. @Steve B., what's wrong with accepting the answer? – Artem Bilan Feb 01 '18 at 14:56
My slf4j is usually quiet by default, but I was having trouble quieting the output in my unit tests. Then this answer reminded me that I'd copied a line from my prod config that was setting up an OnConsoleStatusListener. So all I had to do was remove that. – Shorn Apr 21 '18 at 05:59
In my case INFO logs were caused by "hidden" WARN log about Large window sizes (too big number in rollingPolicy). – lukyer Jun 06 '18 at 11:42
`NopStatusListener` will suppress everything, not just the initialization that the OP wanted to remove – Ghilteras Oct 25 '19 at 05:11
@ArtemBilan "what's wrong with accepting the answer?" I cannot answer for the OP, but for me it simply does **not** work. I added `` to `logback-text.xml` and still I can see the messages `INFO in ch.qos.logback.access.tomcat.LogbackValve[null] - Could NOT configuration file ...` (sic! with the missing "find") etc. – Honza Zidek Nov 26 '20 at 16:18
@HonzaZidek When using Logback-access under Tomcat, you have to add the configuration to a file name logback-access.xml, which should be located in $TOMCAT_HOME/conf/ next to the server.xml-file. Just creating the file will probably work, but otherwise try with the options above. – Rasmus Faber Nov 26 '20 at 18:37
@RasmusFaber I posted a new question https://stackoverflow.com/q/65035615/2886891, because I believe that it is either a different problem or that your solution here does not work. (I also tried adding `` to `logback-text.xml` as you suggested here but with no good result.) – Honza Zidek Nov 27 '20 at 10:22
that status listener element doesn't just work anywhere in the xml file, needs to be up top. What a relieve! All those logback messages were super annoying every time I ran unit tests – Gerry Nov 30 '21 at 16:13

score 49 · Answer 2 · answered Jul 15 '10 at 21:55

49

As described in the docs, if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.

Follow http://logback.qos.ch/codes.html#layoutInsteadOfEncoder i.e. the link mentioned by logback in its warning message. Once you follow the steps mentioned therein, that is, if you replace <layout> element with <encoder>, logback will stop printing messages on the console.

answered Jul 15 '10 at 21:55

Ceki

26,753
7
62
71

4

Sort of right, although you did point me in the right direction. I'd changed to that encoder syntax without effect, although it turns out that removing another line in the logback.xml that was causing a warning did the trick. The deceptive thing about it is that the output seems to be outputting decisions made before it actually parses your logback file, (1>Could NOT find resource [logback.groovy],2>Found resource [logback-test.xml]). It's pretty confusing for a fix in the logback-test to hide status messages for what happens before it gets parsed. But thanks for the pointer. – Steve B. Jul 16 '10 at 13:49
The warning comes from the deprecated element as the warning clearly states. I am afraid I cannot make sense of your last comment. – Ceki Jul 16 '10 at 14:29
5

I think what Steve B. meant is that it's counterintuitive (or at least unconventional) that Logback should suppress *all* status messages, including (and particularly) those that precede the loading of the configuration file, unless it encounters an error later in the configuration. When you are unfamiliar with this rule and first see these status messages (which imply a configurtion warning or error), most users would expect that once the error is resolved, Logback would no longer print the related error messages, but continue to print the other status messages. – Derek Mahar Aug 05 '10 at 16:23
@Steve B.: In case you are curious, I asked a similar question at http://stackoverflow.com/questions/3401051/suppress-all-logback-output-to-console. – Derek Mahar Aug 05 '10 at 16:26
7

FWIW, i also find this quite confusing behaviour. The spew of INFO level messages does a pretty good job of hiding the ERROR messages telling me what i actually need to fix. The lack of a DTD, or any other specification of the syntax of the configuration file, made it quite a trial to debug even once i spotted the message. – Tom Anderson May 08 '11 at 18:34
2

@Ceki: I'm in the same position as binkley in this same post: logback output is only INFO and yet I can't make it go away. Can you please suggest a remedy? I'm using logback-classic/core-0.9.24 and slf4j-api-1.6.1 . – Carl Smotricz Oct 12 '11 at 00:10
5

@Ceki: I finally figured it out: The 2nd way to trigger these messages is to have the `debug="true"` attribute in the `configuration` element of `logback.xml`. Please mention this for the benefit of other people who fall into this hole! – Carl Smotricz Oct 12 '11 at 21:26
6

Perhaps before the first INFO statement there should be a 'Warning detected, outputting all past status info. To stop this message, fix your warnings/errors' – David Roussel May 02 '13 at 19:40

Zineb Hachmaoui · Answer 3 · 2020-02-04T09:23:02.523

9

I had the same problem i added this line

        <!-- Stop output INFO at start -->
        <statusListener class="ch.qos.logback.core.status.NopStatusListener" />

in the logback and it succefully worked

edited Feb 04 '20 at 09:23

answered Feb 04 '20 at 09:17

Zineb Hachmaoui

91
1
2

1

This works, however it prevents ERROR messages output too - no output is produced when serious logback configuration problem occures. – Honza Mar 11 '20 at 16:14

cbaldan · Answer 4 · 2015-03-07T16:32:31.037

Ceki answer is correct:

(...)if warnings or errors occur during the parsing of the configuration file, logback will automatically print status data on the console.

Once you get it right, there won't be any pollution in the first lines of your log anymore.

As of March 2015, in Logback 1.1.2, you need to use <encoder> sub-component - <layout> is now deprecated and if use it, error messages will appear. You cannot control this, it´s Logback default behavior.

Some internal classes have been renamed too, and even the examples in their manual page are outdated!

Here is the code snippet from their Errors Code Help page, which has the correct way to config the logger. This fixed the issue completely in my project. http://logback.qos.ch/codes.html#layoutInsteadOfEncoder

<appender name="FILE" class="ch.qos.logback.core.FileAppender">
  <file>testFile.log</file>
  ...
  <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
    <pattern>%msg%n</pattern>
  </encoder>
</appender>

score 5 · Answer 5 · edited Jan 28 '20 at 09:47

5

I realized Steve found the fix but he didn't mention it on the thread. In case if any other person hit the same issue here is the fix.

Replace "<layout>" elements with "<encoder>..</encoder>"

The culprit is: <layout class="ch.qos.logback.classic.PatternLayout">

edited Jan 28 '20 at 09:47

SkyWalker

28,384
14
74
132

answered Jan 15 '13 at 01:14

Intesar Mohammed

242
3
4

1

If you want to completely remove those messages, use the NopStatusListener as Rasmus described. The encoder vs layout approach does not suppress messages such as 'logback.groovy not found' for example. I'm using logback-classic 1.1.3 (March 2015) – Cristian Botiza Jun 16 '15 at 19:48

Maksym · Answer 6 · 2020-04-09T16:24:20.867

I prefer to use status listener in order to switch off own logback logs:

<configuration>
  <statusListener class="ch.qos.logback.core.status.NopStatusListener" />
  ...
</configuration>

But as was mentioned NopStatusListener also prevents showing warning and errors. So you can write your custom status listener and change log level for it manually:

package com.your.package;

import ch.qos.logback.core.status.OnConsoleStatusListener;
import ch.qos.logback.core.status.Status;

import java.util.List;

public class PrintOnlyWarningLogbackStatusListener extends OnConsoleStatusListener {

    private static final int LOG_LEVEL = Status.WARN;

    @Override
    public void addStatusEvent(Status status) {
        if (status.getLevel() == LOG_LEVEL) {
            super.addStatusEvent(status);
        }
    }

    @Override
    public void start() {
        final List<Status> statuses = context.getStatusManager().getCopyOfStatusList();
        for (Status status : statuses) {
            if (status.getLevel() == LOG_LEVEL) {
                super.start();
            }
        }
    }

}

Then use it in your logback.xml file:

<configuration>
  <statusListener class="com.your.package.PrintOnlyWarningLogbackStatusListener" />
  ...
</configuration>

score 4 · Answer 7 · answered Jul 14 '17 at 10:12

Struggled with the same problem myself i.e. there were a bunch of lines logged right at the beginning which were not related to my code. Here is how I fixed it.

<configuration debug="false">

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <!-- <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level 
        %logger{36} - %msg%n</pattern> </encoder> -->
    <encoder>
        <pattern>%d{HH:mm:ss.SSS} %-5level %logger{10} - %msg%n</pattern>
    </encoder>
</appender>

<root level="error">
    <appender-ref ref="STDOUT" />
</root>

<logger name="fun.n.games" level="DEBUG" />

This is running with the following entry in the pom.xml

        <dependency>
        <groupId>ch.qos.logback</groupId>
        <artifactId>logback-classic</artifactId>
        <version>1.2.3</version>
    </dependency>

Michael-O · Answer 8 · 2016-07-13T07:35:57.540

2

This seems to be Fixed in 0.9.29. Just made several tests. No Joran INFO anymore. I guess this is the fixing commit.

edited Jul 13 '16 at 07:35

answered Nov 17 '11 at 15:43

Michael-O

18,123
6
55
121

score 0 · Answer 9 · answered Jan 22 '15 at 11:03

0

I've tried everything and nothing worked for me. My problem was due to multiple logback.xml files in my classpath. This is the common case in multi modular projects. When there is only one logback.xml file in classpath, there is no ambiguity and the problem is solved.

answered Jan 22 '15 at 11:03

Filip

2,244
2
21
34

what output did it give you? – rogerdpack Dec 23 '19 at 15:28

score 0 · Answer 10 · answered Apr 18 '18 at 10:49

Using the logback.groovy: statusListener(NopStatusListener) (in the src/test/resources/logback.groovy) works.

(A valid use case is e.g. if working with ANT in Eclipse, using logback logging, groovy classes and unit tests where the unit tests take the src/test/resources/logback.groovy, but will also see the src/main/resources/logback.groovy (or similar) you cannot exclude (if ANT's classpath is said to use the projects classpath).)

score 0 · Answer 11 · answered Dec 15 '22 at 18:06

Just for people landing here because of the status messages logged by ch.qos.logback.access.tomcat.LogbackValve#LogbackValve (recent versions). Just set the quiet flag:

var v = new LogbackValve();
v.setQuiet(true); // disable status messages!
v.setFilename("logback-access.xml");

See also the documentation for XML configuration.

How to prevent logback from outputting its own status at the start of every log when using a layout

11 Answers11

Linked

Related