Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'debug' level is getting directed to stderr instead of stdout #927

Closed
rhbecker opened this issue Sep 23, 2016 · 8 comments
Closed

'debug' level is getting directed to stderr instead of stdout #927

rhbecker opened this issue Sep 23, 2016 · 8 comments

Comments

@rhbecker
Copy link

Setup

  • winston version 2.2.0
  • node version 4.4.7

Repro Steps

  1. Save the following into a file named app.js:

    'use strict';
    
    const winston = require('winston');
    const log = new winston.Logger({
    levels: {
      error: 3,
      warning: 4,
      notice: 5,
      info: 6,
      debug: 7,
    },
    transports: [
      new (winston.transports.Console)({
        level: 'debug',
      }),
    ],
    });
    
    log.error('test error');
    log.warning('test warning');
    log.notice('test notice');
    log.info('test info');
    log.debug('test debug');
    
  2. Run the app with command: node app.js > app.log 2>err.log

  3. View the contents of err.log and notice that the log.error and log.debug output both ended up in there (former expected, latter not expected). View the contents of app.log and notice that the log.warning, log.notice, and log.info output all ended up in there (as expected).

  4. Edit app.js to find/replace all 4 instances of 'debug' with any other word - e.g. 'debugz'.

  5. Run the app (again) with (the same) command: node app.js > app.log 2>err.log

  6. Notice how all the stuff ends up in the same file, except that the log.debugz output is now in app.log and not in err.log.

@rhbecker
Copy link
Author

just found related issue #556 ... still trying to understand it, but wanted to get that out there before anyone wastes too much time investigating / responding

@rhbecker
Copy link
Author

Found the answer here:
https://github.com/winstonjs/winston/blob/master/docs/transports.md

... i.e. setting the levels to log to stderr instead of stdout via stderrLevels transport option.

FWIW, I didn't find it very intuitive that this option would default to ['error', 'debug'], but that may be based on my own ignorance of how that default would make sense.

I'll let someone on the project close this issue after reading this feedback, but I need no additional help.

@jasperkuperus
Copy link

Debug logging does not indicate an error in my eyes. Good that it can be changed via stderrLevels, but shouldn't the default be ['error'] in stead of ['error', 'debug']?

@osher
Copy link

osher commented Nov 14, 2017

Maybe I can see the sense of it, although I do not agree with it.

It might make sense under the following terms:

  • you use one main transport that does not go to the console (e.g file, sql, loglly)

In this case, you'll have to search for your debug notices in the file/sql/loglly,
while stderr emits it to your console.

IMHO - It's a kinda twisted gotcha. I'm here just because I ran into it myself, and decided to share my observation.

It's of the kind of settings that are fit to development time, and nowhere else.
IMHO - this behavior should not the default, but enabled by the user.

@hi2u
Copy link

hi2u commented Feb 24, 2018

I agree that this is a very strange default setting.

I'm building a system that runs commands locally, and it also runs its own commands over SSH in child processes too. And have been investigating why the local commands appeared to work (I'm not monitoring STDERR on the main local node process), but the same remote SSH commands were producing STDERR output (I'm throwing local exceptions when the child process's remote command has STDERR output).

First I thought it was something to do with SSH itself handling output differently until I ran further tests to rule SSH out, and after a while thought to look into Winston.

Thanks for posting this issue. This would have taken me a while longer to figure out otherwise.

@indexzero
Copy link
Member

Duplicate of #1024, which will remain open.

The feature has existed for a long time, but if enough folks are not happy with it then we can remove it as a breaking change in winston@4.0.0

@osher
Copy link

osher commented Apr 22, 2018

I think you should let the user decide.
maybe a setting console appender / transport.

@soichih
Copy link

soichih commented May 23, 2018

+1 for leaving debug out of stderr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants