Fairly esoteric question, but for my own edification, I am curious as to how this isn't working.
I have a script fired by a cron running on a legacy system on Rails 2.1
It fetches a list of tasks to execute. Since each task may be long running, it backgrounds the tasks using "fork".
I fetch the pid of the child process. Invoking the process with "RAILS_ENV=Rails.env bundle exec child_script" doesn't work. Dropping the RAILS_ENV does work (Note: running the child script directly from the command line works just fine.)
job_script_path = /path/to/child_script.rb
cmd = "RAILS_ENV=#{Rails.env} bundle exec #{job_script_path}
puts "Preparing to run #{cmd}"
ppid = fork{ system(cmd) }
puts "Fetched #{ppid} as parent process"
cpmd = "ps --ppid #{ppid}"
f = IO.popen(cpmd).readlines
puts "Output of #{cpmd}:"
puts "#{f}"
Invariably outputs:
Preparing to run RAILS_ENV=development bundle exec /path/to/child_script.rb
Fetched 1234 as parent process
Output of ps --ppid 1234
PID TTY TIME CMD
No process listed.
If I drop the RAILS_ENV=#{Rails.env} It works just fine. What about setting the rails environment forces atomicity?
UPDATE: This is more of a Ruby question. I'm running . . . . ruby 1.8.7
Apparently, you cannot fork a concurrent process that runs in a Rails environment. You can, however, fork a concurrent process that does not rely on a Rails environment.
#Do not prepend RAILS_ENV to this, it doesn't allow concurrency (for some reason.)
cmd = "bundle exec #{job.script_path}"
logger.info "Preparing to run #{cmd}"
ppid = fork{ system(cmd) }
logger.info "Fetched #{ppid} as parent process"
Stripping out the Rails env works. I didn't find a definitive resource as to why this is. A Rails environment is somehow monolithic.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.