Skip to content

Instantly share code, notes, and snippets.

@stevenharman

stevenharman/heroku-signals-ticket.md

Last active November 9, 2018 11:12
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save stevenharman/3987569 to your computer and use it in GitHub Desktop.
Save stevenharman/3987569 to your computer and use it in GitHub Desktop.
Download ZIP
Sending user signals to Heroku workers/process...
Raw
heroku-signals-ticket.md

me:

Is it possible to send a signal to a worker/process? I realize the platform sends SIGTERM and SIGKILL when restarting a dyno, but I need to send a USR1 to one of my workers to tell it to stop picking up new jobs. Normally this is achieved via kill -USR1 <pid>, but on the Heroku platform not only do we not know know the pid, we also don't run one-off commands on the same dyno.

Caio (heroku support):

We had this feature experimentally at some point but it was never productized. I recommend you find other ways to signal your processes, like setting a database flag.

me:

Thanks for the quick reply. It is unfortunate that feature has not been further investigated and productized. The suggested workaround is far from ideal, and not very realistic. The whole idea of a USR1 signal is to signal the current process to take some action - in this case, stop taking action. But a new process, which will be spun up after the app is restarted, will have no knowledge of that signal and will get on with doing it's thing - working jobs. Using a database flag introduces a whole host of complexity around managing that state across app restarts and needing to customize (read: hack or monkey patch) existing tools to be aware of that flag.

Caio (heroku support):

That's very reasonable feedback. I'm routing this to our platform engineers.

@stevenharman
Copy link
Author

For anyone coming back to this, years later... it seems Heroku has, quietly, increased the SIGTERM timeout from 10 to 30 seconds. I don't recall seeing any announcement to that effect, but it's mentioned in two different spots in the Heroku Dev Center docs:

  1. https://devcenter.heroku.com/articles/dynos#shutdown
  2. https://devcenter.heroku.com/articles/limits#exit-timeout

Still not ideal, but better, I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment