Forum: Ruby on Rails RE: Does your *shared* hosting account work without errors?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
60e38de043848f82392062088f191213?d=identicon&s=25 Hogan, Brian P. (Guest)
on 2006-02-15 23:17
(Received via mailing list)
Dreamhost works fine for the apps I have. I have to use a modified
dispatch.fcgi file so my app stays stable (no more 500 erros), and I use
cron jobs to keep my applications alive.
828dc634f7493008dbc96c437e54ea2f?d=identicon&s=25 Chris Scharf (scharfie)
on 2006-02-16 02:10
Hogan, Brian P. wrote:
> Dreamhost works fine for the apps I have. I have to use a modified
> dispatch.fcgi file so my app stays stable (no more 500 erros), and I use
> cron jobs to keep my applications alive.

I've been using cron jobs as a keepalive, as well.  Are you using wget
or curl or ?  With wget, I cannot seem to keep it from making an output
file, despite using the switches to disable output.
8e44c65ac5b896da534ef2440121c953?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-02-16 08:00
(Received via mailing list)
On Feb 15, 2006, at 5:10 PM, Chris Scharf wrote:

>
> --
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

	Try this:

wget http://example.com/foo/bar 2>&1 > /dev/null


Cheers-
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ezra@yakima-herald.com
509-577-7732
828dc634f7493008dbc96c437e54ea2f?d=identicon&s=25 Chris Scharf (scharfie)
on 2006-02-16 12:42
Ezra Zygmuntowicz wrote:
> On Feb 15, 2006, at 5:10 PM, Chris Scharf wrote:
>
>>
>> --
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>
> 	Try this:
>
> wget http://example.com/foo/bar 2>&1 > /dev/null
>
>
> Cheers-
> -Ezra Zygmuntowicz
> WebMaster
> Yakima Herald-Republic Newspaper
> ezra@yakima-herald.com
> 509-577-7732


Hmm, seems like no matter what I do I either have output files
generated, or I get emails from cron.

The full line is something like this:

*/5 * * * * wget http://dev.scharfie.com/accounts/login 2>&1 > /dev/null

Any thoughts would be greatly appreciated :-)
0df719ab4c9bcc48a77856c1ec6df2fa?d=identicon&s=25 Andrew Kreiling (agkr)
on 2006-02-16 17:06
Chris Scharf wrote:
>
> Hmm, seems like no matter what I do I either have output files
> generated, or I get emails from cron.
>
> The full line is something like this:
>
> */5 * * * * wget http://dev.scharfie.com/accounts/login 2>&1 > /dev/null
>
> Any thoughts would be greatly appreciated :-)

I've have to reverse the redirections on some systems for it to work
properly in cron.  Not sure why.  Anyway try:

*/5 * * * * wget http://dev.scharfie.com/accounts/login > /dev/null 2>&1

-a
Ef3aa7f7e577ea8cd620462724ddf73b?d=identicon&s=25 Rob Biedenharn (Guest)
on 2006-02-16 17:38
(Received via mailing list)
At 2/16/2006 11:06 AM, you wrote:
>
>I've have to reverse the redirections on some systems for it to work
>properly in cron.  Not sure why.  Anyway try:
>
>*/5 * * * * wget http://dev.scharfie.com/accounts/login > /dev/null 2>&1
>
>-a


The redirections are processed when encountered so "2>&1" means
"connect STDERR to whatever STDOUT is right now" which is probably
being captured by cron and then you change STDOUT to go to /dev/null.

cron probably acts something like:
(command) >watchoutput 2>&1 <&-
if [[ -s watchoutput ]]; then mail user < watchoutput; fi

When you put your actual command in and expand what the shell will do
*in the order that it would appear to happen*, you'd get:

wget http://dev.scharfie.com/accounts/login >watchoutput 2>&1
<&- >/dev/null 2>&1

send stdout to watchoutput
send stderr to where stdout goes (and that's watchoutput)
close stdin  (it might be closer to "</dev/null" than "<&-", but the
point is the same)
call the user's command
send stdout to /dev/null
send stderr to where stdout goes (and that's /dev/null)
wait for command to finish
see if there's any output in watchoutput and email it to user

-Rob
This topic is locked and can not be replied to.