Forum: Ruby on Rails backgroundjob (bj) stopped working

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.
Af9a9013100ddf2dbb0ca13487b60f8b?d=identicon&s=25 Ivor Paul (ivor)
on 2008-11-19 13:30
(Received via mailing list)
Hi

We have been using bj for a while now to upload images to S3 for
storage.
Everything was running fine, but recently bj has completely stopped
working.

In the past Bj would just start working when I started mongrel. I
found that if I logged into the console and issued

Bj.run

Bj would run perfectly, however, failing to do that and no bj for me :)

Any thoughts?

We are running on Rails 2.2 but I am hoping it is related to something
else.

Ivor
Af9a9013100ddf2dbb0ca13487b60f8b?d=identicon&s=25 Ivor Paul (ivor)
on 2008-11-19 16:27
(Received via mailing list)
For educational purposes - does no one have an opinion, or did I not
qualify this question well enough?

I
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2008-11-19 16:31
(Received via mailing list)
On 19 Nov 2008, at 15:20, Ivor Paul wrote:

>
> For educational purposes - does no one have an opinion, or did I not
> qualify this question well enough?

Either that or
- it's only been three hours
- it's only 10 am on the east coast and 7am pacific.
- you haven't actually provided much information apart from "it
doesn't work" (is the runner running/not running/failing to start? Is
it starting and then crashing, if so is it producting any output (logs
etc...)

Fred
Af9a9013100ddf2dbb0ca13487b60f8b?d=identicon&s=25 Ivor Paul (ivor)
on 2008-11-19 16:46
(Received via mailing list)
Cool, thanks

I compared my email to the other emails that came after mine and just
wondered what the difference was. I do realize that this isn't a very
general problem. Im sitting at GMT +2 so didn't realise how early it
was in im guessing the east coast of the usa.

In the past, we had a after_create function in a model that submitted
a task to Bj. Bj would as expected pick this up and execute the task.
We did not have the runner configured to run in cluster mode, but let
Bj manage itself.

Recently, we saw that although the jobs were being created:

Bj.table.job.all =>
[#<Bj::Table::Job bj_job_id: 4, command: "tail -n 500
log/development.log", state: "pending", priority: 0, tag: "",
is_restartable: 1, submitter: "TheLuggage", runner: nil, pid: nil,
submitted_at: "2008-11-19 14:43:28", started_at: nil, finished_at:
nil, env: nil, stdin: nil, stdout: nil, stderr: nil, exit_status:
nil>, #<Bj::Table::Job bj_job_id: 5, command:
"/home/someuser/someproject/script/runner \"Image.f...", state:
"pending", priority: 0, tag: "", is_restartable: 1, submitter:
"TheLuggage", runner: nil, pid: nil, submitted_at: "2008-11-19
14:50:25", started_at: nil, finished_at: nil, env: nil, stdin: nil,
stdout: nil, stderr: nil, exit_status: nil>, #<Bj::Table::Job
bj_job_id: 6, command: "/home/someuser/someproject/script/runner
\"Image.f...", state: "pending", priority: 0, tag: "", is_restartable:
1, submitter: "TheLuggage", runner: nil, pid: nil, submitted_at:
"2008-11-19 14:50:49", started_at: nil, finished_at: nil, env: nil,
stdin: nil, stdout: nil, stderr: nil, exit_status: nil>,
#<Bj::Table::Job bj_job_id: 7, command:
"/home/ivor/workspace/talkies/script/runner \"Image.f...", state:
"pending", priority: 0, tag: "", is_restartable: 1, submitter:
"TheLuggage", runner: nil, pid: nil, submitted_at: "2008-11-19
14:52:55", started_at: nil, finished_at: nil, env: nil, stdin: nil,
stdout: nil, stderr: nil, exit_status: nil>, #<Bj::Table::Job
bj_job_id: 8, command: "/home/someuser/someproject/script/runner
\"Image.f...", state: "pending", priority: 0, tag: "", is_restartable:
1, submitter: "TheLuggage", runner: nil, pid: nil, submitted_at:
"2008-11-19 14:55:33", started_at: nil, finished_at: nil, env: nil,
stdin: nil, stdout: nil, stderr: nil, exit_status: nil>,
#<Bj::Table::Job bj_job_id: 9, command:
"/home/someuser/someproject/script/runner \"Image.f...", state:
"pending", priority: 0, tag: "", is_restartable: 1, submitter:
"TheLuggage", runner: nil, pid: nil, submitted_at: "2008-11-19
14:55:54", started_at: nil, finished_at: nil, env: nil, stdin: nil,
stdout: nil, stderr: nil, exit_status: nil>]

However, the jobs are never executed. It feels like what ever couping
there was with Bj and the script/server is missing.

 Bj.runner.ping
=> nil

Bj.runner.tickle
=> {"pid"=>11693, "command"=>"/usr/bin/ruby1.8
\"/home/someuser/someproject/script/bj\" \"run\" \"--forever\"
\"--redirect=/home/someuser/someproject/log/bj.TheLuggage.development.log\"
\"--ppid=11445\" \"--rails_env=development\"
\"--rails_root=/home/someuser/someproject\""}

We are running Rails2.2

I will be more than willing to provide additional information - not
sure what would help.
Thanks for the feedback.

Ivor

On Wed, Nov 19, 2008 at 5:30 PM, Frederick Cheung
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2008-11-19 17:12
(Received via mailing list)
On Nov 19, 3:46 pm, "Ivor Paul" <ivorp...@gmail.com> wrote:
> Cool, thanks
>
> I compared my email to the other emails that came after mine and just
> wondered what the difference was. I do realize that this isn't a very
> general problem. Im sitting at GMT +2 so didn't realise how early it
> was in im guessing the east coast of the usa.
>
The other thing is how many people are using bj ( I for example have
never used it). You may find that there are more people using it on
ruby-talk
> \"--redirect=/home/someuser/someproject/log/bj.TheLuggage.development.log\"
> \"--ppid=11445\" \"--rails_env=development\"
> \"--rails_root=/home/someuser/someproject\""}

Have your checked that that log file doesn't have any clues and that
all of those paths are sane? You want to be able to tell the
difference between the task runner thing not even trying to run your
tasks and trying but failing.

Fred
This topic is locked and can not be replied to.