Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dont deamonize #875

Closed
emilebosch opened this issue Feb 5, 2016 · 6 comments
Closed

Dont deamonize #875

emilebosch opened this issue Feb 5, 2016 · 6 comments

Comments

@emilebosch
Copy link

Hey in order to have our workers to run efficiently in docker we would love to have it not demonize when starting. So it can say pid one1. Is there an option to do this?

@betamatt
Copy link
Collaborator

betamatt commented Feb 5, 2016

If I'm understanding the question correctly then you're in a situation similar to people running DJ on Heroku. Use the run command instead of start, which will prevent the the parent process from daemonizing.

@albus522
Copy link
Member

albus522 commented Feb 5, 2016

Or run via rake https://github.com/collectiveidea/delayed_job#running-jobs

@albus522 albus522 closed this as completed Feb 5, 2016
@rbalman
Copy link

rbalman commented Jan 8, 2017

But I don't know how to make --pid-dir work while starting delayed_job as run or the rake task jobs:work. I needed the pid file because I want to fire certain signal to the pid while deploying my codebase. Guys any suggestions?

@zx1986
Copy link

zx1986 commented Aug 1, 2017

@javanux or try this base image? https://github.com/phusion/baseimage-docker

@albus522
Copy link
Member

albus522 commented Aug 1, 2017

You can write a pid file manually by creating a simple plugin. Put something like this in the delayed job initializer or anywhere that is guaranteed to load.

class WritePidfile < Delayed::Plugin
  callbacks do |lifecycle|
    lifecycle.before(:execute) do |_worker|
      File.write("path/to/pidfile", "w") {|f| f.puts Process.pid }
    end
  end
end

jdufresne added a commit to jdufresne/delayed_job that referenced this issue Feb 3, 2024
The new plugin creates a pidfile at location
`#{Rails.root}/tmp/delayed_job.pid` when a worker starts and then
removes it when a worker stops. It uses `lifecycle.around(:execute)` to
achieve this.

The file is created in "write exclusive" mode. This means if the file
already exists, a Errno::EEXIST exception is raised. This ensures that a
worker doesn't overwrite a pidfile in use.

This plugin is useful to allow an outside observer (e.g. a healthcheck)
to check if the worker started successfully.

The plugin is not installed by default for backwards compatibility.
Users can use it by adding to their initializer:

Delayed::Worker.plugins << Delayed::Plugin::Pidfile

refs collectiveidea#875
jdufresne added a commit to jdufresne/delayed_job that referenced this issue Feb 3, 2024
The new plugin creates a pidfile at location
`#{Rails.root}/tmp/delayed_job.pid` when a worker starts and then
removes it when a worker stops. It uses `lifecycle.around(:execute)` to
achieve this.

The file is created in "write exclusive" mode. This means if the file
already exists, `Errno::EEXIST` is raised. This ensures that a worker
doesn't overwrite a pidfile in use.

This plugin is useful to allow an outside observer (e.g. a healthcheck)
to check if the worker started successfully.

The plugin is not installed by default for backwards compatibility.
Users can use it by adding to their initializer:

Delayed::Worker.plugins << Delayed::Plugin::Pidfile

refs collectiveidea#875
@jdufresne
Copy link

jdufresne commented Feb 3, 2024

You can write a pid file manually by creating a simple plugin. Put something like this in the delayed job initializer or anywhere that is guaranteed to load.

class WritePidfile < Delayed::Plugin
  callbacks do |lifecycle|
    lifecycle.before(:execute) do |_worker|
      File.write("path/to/pidfile", "w") {|f| f.puts Process.pid }
    end
  end
end

Thanks for this suggestion. I needed something like this and thought it might be useful to other people. So I put it into PR #1202.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants