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
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 On Jun 6, 2006, at 11:37 PM, Paul Rush wrote:> 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?
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 On 6/7/06, Brian Hughes <brianvh@alum.dartmouth.org> wrote:> > 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 > > On Jun 6, 2006, at 11:37 PM, Paul Rush wrote: > > 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? > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
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
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 On 6/7/06, Brian Hughes <brianvh@alum.dartmouth.org> wrote:> 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 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
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
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
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 On 6/7/06, Brian Hughes <brianvh@alum.dartmouth.org> wrote:> 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 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
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 On Jun 7, 2006, at 09:23 PM, Paul Rush wrote:> 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.
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 On 6/7/06, Brian Hughes <brianvh@alum.dartmouth.org> wrote:> > 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 > > > On Jun 7, 2006, at 09:23 PM, Paul Rush wrote: > > 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. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >