Why does Mojo::Server::Daemon debugging print to STDERR?

516 views
Skip to first unread message

Nathan Waddell

unread,
Apr 3, 2015, 3:30:59 PM4/3/15
to mojol...@googlegroups.com
Setting the MOJO_DAEMON_DEBUG environment variable causes debugging messages to be printed to STDERR. Why does it use STDERR and not STDOUT? Debugging messages aren't errors, they are expected behavior in debugging mode.

Nathan Waddell

unread,
Apr 3, 2015, 6:04:36 PM4/3/15
to mojol...@googlegroups.com
After some research, it looks like this is because Mojo::Log defaults to STDERR:

has handle => sub {
 
  # STDERR
  return \*STDERR unless my $path = shift->path;
 
  # File
  croak qq{Can't open log file "$path": $!} unless open my $file, '>>', $path;
  return $file;
};

How would I configure hypnotoad to use STDOUT for Mojo::Log instead?

Dan Book

unread,
Apr 3, 2015, 7:55:27 PM4/3/15
to mojol...@googlegroups.com
$app->log->handle(\*STDOUT); (untested)

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Dan Book

unread,
Apr 3, 2015, 7:56:17 PM4/3/15
to mojol...@googlegroups.com
Also note this will affect all app log output, including errors.

Jan Henning Thorsen

unread,
Apr 4, 2015, 3:50:01 AM4/4/15
to mojol...@googlegroups.com
Note that MOJO_DAEMON_DEBUG (and similar environment variables) does not use Mojo::Log, but simply print to screen using "warn":


The reason I don't want them to screen is that they would clutter the "real" output from a script. Consider this:

  MOJO_USERAGENT_DEBUG=1 mojo get mojolicio.us 1>index.html 2>index.html.log

Using "print" instead of "warn" would result in an unexpected outcome.


On Saturday, April 4, 2015 at 1:56:17 AM UTC+2, Dan Book wrote:
Also note this will affect all app log output, including errors.
On Fri, Apr 3, 2015 at 7:55 PM, Dan Book <gri...@gmail.com> wrote:
$app->log->handle(\*STDOUT); (untested)
On Fri, Apr 3, 2015 at 6:04 PM, Nathan Waddell <arafe...@gmail.com> wrote:
After some research, it looks like this is because Mojo::Log defaults to STDERR:

has handle => sub {
 
  # STDERR
  return \*STDERR unless my $path = shift->path;
 
  # File
  croak qq{Can't open log file "$path": $!} unless open my $file, '>>', $path;
  return $file;
};

How would I configure hypnotoad to use STDOUT for Mojo::Log instead?


On Friday, April 3, 2015 at 2:30:59 PM UTC-5, Nathan Waddell wrote:
Setting the MOJO_DAEMON_DEBUG environment variable causes debugging messages to be printed to STDERR. Why does it use STDERR and not STDOUT? Debugging messages aren't errors, they are expected behavior in debugging mode.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious+unsubscribe@googlegroups.com.

Nathan Waddell

unread,
Apr 6, 2015, 10:49:37 AM4/6/15
to mojol...@googlegroups.com
Looking at the source, I do indeed see that it uses warn.

I am deploying hypnotoad as a foreground process being run and monitored under a service manager. This service manager is designed along UNIX conventions, one of which is that STDERR should be reserved for true errors. 

I think I could create a warn handler, but I imagine there would still be difficulty separating true warns from simple debugging. Is there a technique I could employ to work around this? 

sri

unread,
Apr 6, 2015, 10:53:42 AM4/6/15
to mojol...@googlegroups.com
I am deploying hypnotoad as a foreground process being run and monitored under a service manager. This service manager is designed along UNIX conventions, one of which is that STDERR should be reserved for true errors.

Just to be absolutely clear, unlike the application logger, those debug messages are not a supported feature. They are meant for core developers, and will not be made any more friendly than absolutely necessary.

--
sebastian

Nathan Waddell

unread,
Apr 6, 2015, 10:54:21 AM4/6/15
to mojol...@googlegroups.com
Would there be value seen in a patch that allowed a log path to be used as the value of MOJO_DAEMON_DEBUG?

MOJO_DAEMON_DEBUG='/var/log/mojo.debug'

sri

unread,
Apr 6, 2015, 10:56:49 AM4/6/15
to mojol...@googlegroups.com
Would there be value seen in a patch that allowed a log path to be used as the value of MOJO_DAEMON_DEBUG?

It would get rejected.

--
sebastian 

sri

unread,
Apr 6, 2015, 10:58:00 AM4/6/15
to mojol...@googlegroups.com
It would get rejected.

In fact, this thread makes me wonder if all *_DEBUG environment variables should be removed or made completely private.

--
sebastian

Jan Henning Thorsen

unread,
Apr 6, 2015, 11:01:07 AM4/6/15
to mojol...@googlegroups.com
That is simply not true. STDERR is not just for "errors", despite the name. It is also for diagnostic messages, and pretty much anything that should not be considered the "regular ouput" from the application.

I will never vote in favor of allowing any such DEBUG messages (enabled by an environment variable) to be sent to a log file. You could however do it manually by redirecting STDERR (2) to a log file.

When that is said: This should never ever be done in production. Doing so adds an overhead that slows down your application.

The STDERR constants used through Mojolicous (and other CPAN modules) are simply for developers to get that extra bit of information about what is going on under the hood when nothing else makes sense.

I also have no idea why you want this. You ask for something, without explaining what it solves.

Nathan Waddell

unread,
Apr 9, 2015, 6:43:12 PM4/9/15
to mojol...@googlegroups.com
I'm fine with no value being seen in the suggestion. I'm also fine with the suggestion being rejected. That's why I asked. I have no interest in writing patches no-one wants, so I wanted to see what the community thought before working on it. I'm looking to contribute, not get in anyone's way.

I have the great pleasure of being able to use Mojolicious in my #dayjob, and unfortunately cannot really share too many details about that. I can say that my mojo apps are deployed under a service manager. This basically daemonizes apps and distributes the application processing across the supercomputer on which it runs.

This manager uses STDOUT/STDERR for logging/alerting. I am told by The Powers Who Be that the "UNIX philosophy" is that STDERR is for errors.

I actually disagree with this, but have to solve the situation somehow. It's my problem, and I certainly don't expect the community to solve it.

I just thought that if I was going to have to find a solution for this (rather unique) situation, that there might be some value seen in it by others.

Dan Book

unread,
Apr 9, 2015, 8:37:22 PM4/9/15
to mojol...@googlegroups.com
In this case though, it's not really about STDERR being for errors: it's about DEBUG output being for development of Mojo and related modules, not end-user applications. I will use it from time to time to debug a critical issue, for example to see exactly what is being passed by Mojo::UserAgent or a server, but for general operation it should not be necessary.

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.

Helmut Wollmersdorfer

unread,
Apr 10, 2015, 6:53:08 AM4/10/15
to mojol...@googlegroups.com


Am Freitag, 10. April 2015 00:43:12 UTC+2 schrieb Nathan Waddell:

This manager uses STDOUT/STDERR for logging/alerting. I am told by The Powers Who Be that the "UNIX philosophy" is that STDERR is for errors.

For systems in production this is right. So just don't use DEBUG in production.

As the word says it should only used for debugging, diagnosing complex unexpected behaviour. I.e. during development or occasionally during automated testing.

Helmut Wollmersdorfer
Reply all
Reply to author
Forward
0 new messages