Lighttpd/fastcgi - where does stdout go?

Rails
1

i’m using lighty and fastcgi in my rails production environment.
standard output appears to get swallowed up somewhere… it’s clearly
not coming out of the development log. don’t know where to look for
it.

is this a byproduct of running in production mode? is there a way to
turn this off?

thanks,
paul

2

I’m not quite sure what you are referring to… Are you using the -D
option in your call to lighttpd? That tells lighty to run in daemon
mode, which suppresses the output that would normally appear on
standard output.

-Brian

3

On Jun 7, 2006, at 12:06 PM, Paul Rush wrote:

yup, i’m talking about running lighty as a daemon. obviously, standard
out won’t appear on any console…

but shouldn’t it then get redirected to a log somewhere? ideally one
could configure where standard out goes when running as a daemon,
other servers let you do this.

Ah… OK. Yes. In the lighty config file there should be a setting
for the Access Log and the Error Log. Those are the files that will
have the std-out data appended to them. If you use lighty for
development, look in the log folder and you should see
lighttpd.access.log and lighttp.error.log.

That’s where the default Rails lighttpd config file, located in
config, stores the standard log data.

-Brian

4

yup, i’m talking about running lighty as a daemon. obviously, standard
out won’t appear on any console…

but shouldn’t it then get redirected to a log somewhere? ideally one
could configure where standard out goes when running as a daemon,
other servers let you do this.

p

5

ok, still not quite there. i’m curious where standard out goes in
production mode, not development mode. although now that i check
stdout disappears on both production and development mode with lighty.

no log files contain stdout messages either. is that the behavior
that’s to be expected?

all i want is a simple:
puts ‘hi’
to show up somewhere.

thanks,
paul

6

On Wed, Jun 07, 2006 at 05:04:51PM -0700, Paul Rush wrote:

ok, still not quite there. i’m curious where standard out goes in
production mode, not development mode. although now that i check
stdout disappears on both production and development mode with lighty.

no log files contain stdout messages either. is that the behavior
that’s to be expected?

all i want is a simple:
puts ‘hi’
to show up somewhere.

Y’know, RAILS_DEFAULT_LOGGER.info(‘hi’) is only a few more keystrokes,
and I
know exactly where that’s going to go (log/$RAILS_ENV.log).

  • Matt
7

On Jun 7, 2006, at 08:04 PM, Paul Rush wrote:

ok, still not quite there. i’m curious where standard out goes in
production mode, not development mode. although now that i check
stdout disappears on both production and development mode with lighty.

no log files contain stdout messages either. is that the behavior
that’s to be expected?

all i want is a simple:
puts ‘hi’
to show up somewhere.

You’ve lost me again… Lighttpd is an http server process. It’s only
output, other than possible error messages, are relevant only in an
http request/response context. You shouldn’t ever see the actual
method/page output as the output of the server process.

So, the real question is, what exactly are you trying to do? And why
are you expecting lighttpd to be the place where your expected output/
result should show?

-Brian

8

Hey, Paul. If you think using the Logger will work for you, then you
should probably run with it. However, I’ve got one very important
thing to say about how you are currently “debugging” your Rails code:
Use the Built-In Testing Framework!

In fact, this really goes for everyone out there doing their
“testing” and “debugging” in this manner.

Use Unit tests for your Models and /lib classes. Use Functional tests
to make sure your Controllers are doing the right thing and returning
the proper XHTML. If you want to get really fancy, you can build out
entire User Stories for your app with Integration tests.

What you don’t want to do is continue to rely on hacks like put
statements or debug log outputs for your web-based applications. They
aren’t repeatable and they are effectively impossible to document.
Writing tests is the only way to gain real confidence that your code
works. And without those tests, any refactoring you plan to do will
be that much harder to pull off, if you don’t really know what impact
those changes have on the rest of your app.

Sorry for the rant, gang, but I’ve been where Paul is. It took me a
while to “see the light” in terms of good, repeatable tests, but once
I did, I pretty much can’t imagine doing with out them. In fact, I’ve
found that I actually prefer the TDD/BDD methodology of writing the
test (or specification) first, and then writing the code that makes
that test pass. Granted, this method won’t be for everyone, but that
doesn’t mean you should skip using the /test directory. It may seem
like extra work, but everything I’ve seen has convinced me that it’s
totally worth it. Plus, I’m pretty sure I was spending just as much
time trying to debug my bad code as I do, writing the test first and
then coding to make the test pass…

-Brian

9

i’m in the process of deploying an app that i’ve been developing with
webrick to lighttpd/fastcgi. i’m used to doing quick and dirty
debugging by sprinkling a controller or a library with puts
statements. i started debugging the production version of my app and
suddenly i couldn’t find my trusty puts statements. normally these
statements show up on the webrick console (similar to tomcat and
apache in some contexts)… but they fail to show up anywhere now. i
was wondering why and couldn’t find anything on the web, so i posted
here. brian - does that make sense?

a friend of mine just told me that fastcgi throws standard out into
the http response… which would make sense, i suppose. i just
figured fastcgi worked like other web environments i’m used to where
behind the scenes there is some special io handle that your app is
writing to when it renders html response. so i take it fastcgi just
renders everything to stdout and passes it on to lighttpd?

and matthew - yeah, i’ll probably just start using a logger for my
debugging output from now on… finer granularity and better output
routing definitely sound like a good way to go.

btw, thanks yall…

p

10

amen! tests have changed everything about the way i develop. i agree
with you wholeheartedly.

on the project i’m working on, we’re deploying to a server that we
didn’t set up and one that has slightly different configuration in
production mode. test suites will pass, but every once in a while you
need to quickly see what a config variable is set to, or something
similar. the fastest was to see that is to print something out…
didn’t have loggers set up, but will probably go that route from now
on.

this all arose from curiosity and unfamiliarity with the internals of
fastcgi/lighttpd… it’s not the end of the world… but i’m still
curious strictly ouf the desire to understand;
where does stdout go in a fastcgi environment?

p