coffee-resque icon indicating copy to clipboard operation
coffee-resque copied to clipboard

process.title

Open AurelienGasser opened this issue 13 years ago • 7 comments

Hey, Thanks for coffee-resque, it's awesome. I'm having a question though : is the changing of the process title mandatory ? It is causing me problems on heroku: since the process title has changed, I cannot catch signals (like SIGTERM) sent to it :( If I don't call worker.start() I have no issue catching the signal, I guess it's because as long as the worker has not started, the process title is not modified.

AurelienGasser avatar Jan 23 '12 11:01 AurelienGasser

It is not, but ruby resque does this too I believe. I think this feature is really to allow you too see what worker is running if you were use the ps command.

I'm curious if this is the actual issue on heroku though. If you could include the coffee resque js file with your source and exclude it from your package.json file you could hack around resque to determine if this is the source of the lost signal.

Let me know what you find out.

Sent from my iPhone

On Jan 23, 2012, at 6:20 AM, Auré[email protected] wrote:

Is the changing of the process title mandatory ? It is causing me problems on heroku: since the process title has changed, I cannot catch signals (like SIGTERM) sent to it :( If I don't call worker.start() I have no issue catching the signal, I guess it's because as long as the worker has not started, the process title is not modified.


Reply to this email directly or view it on GitHub: https://github.com/technoweenie/coffee-resque/issues/19

steelThread avatar Jan 23 '12 12:01 steelThread

@momow Were you able to verify that the process title is the actual problem on heroku?

steelThread avatar Jan 25 '12 01:01 steelThread

@steelThread I did like you suggested. I created a fresh heroku app

1/ Keeping coffee-resque.js at it is : no SIGTERM caught 2/ Commenting the process.title = xxx : SIGTERM caught

Thus confirming the process.title issue with heroku

Here is my test.js file : https://gist.github.com/1688410

AurelienGasser avatar Jan 27 '12 11:01 AurelienGasser

Thanks for digging a little deeper. I'll look into this in further detail.

steelThread avatar Jan 27 '12 13:01 steelThread

confirmed locally. foreman will lost control of workers if process.title is reassigned.

RobinQu avatar Aug 06 '12 03:08 RobinQu

So I tried this locally with foreman v0.57.0 and node v0.8.8 using @momow's code above as an example. I receive the SIGTERM in the node process when I issue a SIGTERM to the foreman : master process via kill. SIGINT on the foreman : master process will not send a SIGTERM to the node process although foreman says it is trying to do so.

So I deployed the same code to Heroku and after I finally got it all set up I'm noticing that I do receive a SIGTERM when I push the repo (see below) to Heroku or when I scale the ps to 0. Maybe I'm missing a step required to reproduce this error. Here's my codez

package.json

{
  "name": "resque-test",
  "version": "0.0.1",
  "dependencies": {
    "coffee-resque": "0.1.7",
    "redis": "~0.7.2",
    "hiredis": "~0.1.14"  },
  "engines": {
    "node": "0.8.7",
    "npm": "1.1.49"
  }
}

Script

var resque = require('coffee-resque')

process.on('SIGTERM', function() {
  console.log('SIGTERM SIGNAL CAUGHT!!!')
  process.exit(0)
})

var rtg   = require("url").parse(process.env.REDISTOGO_URL)
var redis = require("redis").createClient(rtg.port, rtg.hostname)
redis.auth(rtg.auth.split(':')[1])

var worker = resque.connect({
  redis: redis
}).worker('testqueue', {
  new_message: function() { }
})
worker.start()

// listen on $PORT so that heroku doesn't kill the app
var http = require('http')
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'})
  res.end('Hello World\n');
}).listen(process.env.PORT)

Heroku Log

2012-08-29T19:39:31+00:00 heroku[web.1]: State changed from up to starting
2012-08-29T19:39:32+00:00 heroku[slugc]: Slug compilation finished
2012-08-29T19:39:35+00:00 heroku[web.1]: Starting process with command `node test.js`
2012-08-29T19:39:35+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2012-08-29T19:39:36+00:00 app[web.1]: SIGTERM SIGNAL CAUGHT!!!
2012-08-29T19:39:36+00:00 heroku[web.1]: State changed from starting to up
2012-08-29T19:39:37+00:00 heroku[web.1]: Process exited with status 0
2012-08-29T20:02:57+00:00 heroku[slugc]: Slug compilation started
2012-08-29T20:03:06+00:00 heroku[api]: Release v13 created by [email protected]
2012-08-29T20:03:06+00:00 heroku[api]: Deploy 1750bee by [email protected]
2012-08-29T20:03:06+00:00 heroku[web.1]: State changed from up to starting
2012-08-29T20:03:07+00:00 heroku[slugc]: Slug compilation finished
2012-08-29T20:03:08+00:00 heroku[web.1]: Starting process with command `node test.js`
2012-08-29T20:03:10+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2012-08-29T20:03:11+00:00 app[web.1]: SIGTERM SIGNAL CAUGHT!!!
2012-08-29T20:03:12+00:00 heroku[web.1]: Process exited with status 0

steelThread avatar Aug 29 '12 20:08 steelThread

Maybe this helps: https://github.com/defunkt/resque/issues/368

Another issue regarding changing process.title is that there are chances you will lose console logs of worker processes in "heroku logs -t"

RobinQu avatar Sep 07 '12 08:09 RobinQu