# Finding where STDOUT/STDERR debug messages are coming from

DevFeed: [Finding where STDOUT/STDERR debug messages are coming from](<https://devfeed.tech/articles/finding-where-stdout-stderr-debug-messages-are-coming-from-22430.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2018/08/07/finding-where-stdout-stderr-debug-messages-are-coming-from>)

Author: Sam Saffron

Published: 2018-08-07T06:06:55Z

Content type: tutorial

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [debug](<https://devfeed.tech/topics/debug.md>), [Development](<https://devfeed.tech/topics/development.md>), [servers](<https://devfeed.tech/topics/servers.md>), [Sidekiq](<https://devfeed.tech/topics/sidekiq.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [c-sharp](<https://devfeed.tech/tags/c-sharp.md>), [console](<https://devfeed.tech/tags/console.md>), [debug](<https://devfeed.tech/tags/debug.md>), [debugger](<https://devfeed.tech/tags/debugger.md>), [development](<https://devfeed.tech/tags/development.md>), [net](<https://devfeed.tech/tags/net.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [saffron](<https://devfeed.tech/tags/saffron.md>), [sam](<https://devfeed.tech/tags/sam.md>), [server](<https://devfeed.tech/tags/server.md>), [sidekiq](<https://devfeed.tech/tags/sidekiq.md>), [sql](<https://devfeed.tech/tags/sql.md>), [weblog](<https://devfeed.tech/tags/weblog.md>)

## AI overview

A debugging tip for tracing unexpected messages printed to STDOUT or STDERR in development. The article shows how to reopen STDERR and attach a method that prints caller locations when write is invoked, helping identify the source of stray output in web servers, test suites, or upgraded gems.

## Source excerpt

Recently, we have been experiencing "stalls" in the Puma web server in development, this means that quite often during our dev cycle we would hit CTRL-C and be stuck waiting many many seconds for Puma to stop. Sometimes needing to fallback to kill -9 on the Puma process. We definitely want this Puma issue fixed, however our "web application server of choice" is Unicorn not Puma. It makes little sense for us to run Puma in development. Our Unicorn configuration is very mature and handles all sorts of magic including automatic forking of our Sidekiq job scheduler which is awesome in dev. A major problem though is that when we run Puma in dev our console is pristine, run Unicorn in dev and it is noise central. 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/pretty-text-bundle.js?1533620338.6222095 HTTP/1.1" 200 112048 0.0481 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/plugin.js?1533620338.6222444 HTTP/1.1" 200 146176 0.0726 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/plugin-third-party.js?1533620338.6222594 HTTP/1.1" 200 3364 0.0569 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/application.js?1533620338.6222193 HTTP/1.1" 200 3039095 0.2049 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/fontawesome-webfont.woff2?http://l.discourse&2&v=4.7.0 HTTP/1.1" 304 - 0.0016 I am a puts debugger and being barred from being a puts debugger in development is a blocking feature for me. So, how do we find where these messages are coming from? Before we start the little tip here first... if you have not yet... take a break and read _why's classic seeing metaclasses clearly. Now that you know about metaclasses, time to have some fun, let's reopen STDERR and glue a little debug method to it that will output caller locations when we invoke write on STDERR (note this will work on STDOUT as well if you want): class << STDERR alias_method :orig_write, :write def write(x) orig_write(caller[0..3].join("\n")) orig_write(x) end end /home/sam/.rbenv/v