-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
RFC: Remove daemonization and logging control? #4045
Comments
I'd still like the ability to have a pid file. This may be a case of me being "old", but I've typically always worked in pids and sending signals to processes through pids. Personally, I set up my supervisors to monitor pids, again this is probably a result of me just doing things "the old way". The rest of the proposed changes I'm alright with. |
@t27duck What do you use to supervise Sidekiq? Typically you can get the PID from the supervisor, with |
Yeah, admittedly I use systemd and just give it the location of the PID file to use. My problem is I haven't gotten around to "fixing" them to do it the right way, mainly due to "they work fine for me as-is" today. Figure it's worth a shot to keep me from having to redo my configs. :D |
Reframe it as "simplifying" your configs and it makes more sense. :-) systemd's PIDFile= option is really necessary to support services which only support old-style double forking. |
+1 for this! Regarding logging, I would love to be able to have Sidekiq output logs in a formatted format (be it JSON or anything else, or make it modular). This would be really helpful when you want to analyse them. I know it is possible to create a custom logger, but this should be in core imo. |
Note to readers: I also wrote this blog post over four years ago about how daemonization is a terrible thing. This proposal has been a long time coming. https://www.mikeperham.com/2014/09/22/dont-daemonize-your-daemons/ |
@renchap I would consider inclusion in core if you want to submit a PR. |
If PID files are removed, we break the quiet/shutdown features of sidekiqctl. I'll have to remove that too; sidekiqctl always implied that you were using sidekiq in :daemon mode. |
Would there be a replacement/equivalent for telling sidekiq to stop collecting new jobs due to a soon-to-be shutdown? |
@t27duck I guess for
|
Sounds great. Good separation of concerns and some sensible changes that I’ve been interested in from time to time after years of using sidekiq. |
Hello, I just wanted to let you know about one use-case that this will affect, and I wanted to see if there might be a better way for me to accomplish the same goal. Some context: I accidentally deployed a change that caused my Sidekiq workers to crash on boot. (Fortunately I had zero downtime and the deploy was rolled back automatically.) This was an error that happened in a I've now added an actual end-to-end worker test to my CI build, where I start a real Sidekiq process, and run a real job through Redis. Here's a gist that contains my "sanity check" script, and also a WorkerHealthCheckJob that just writes some data to a temporary file. I'm using the Now that these flags are being removed, I think I can just run Sidekiq in the background and get the PID from
So that's not too much of a problem! I just wanted to let you know about this use-case and see if you might have any feedback or suggestions about end-to-end testing in CI. UPDATE: This works totally fine: https://gist.github.com/ndbroadbent/ea32c513f43917a844903760831ec9d3 UPDATE 2: Sorry I spoke too soon, I think this worked locally on my Mac, but I couldn't get it to work on CI. (I think it's something to do with the TTY.) I could only get this to work by using the |
An alternative is to use a You need |
Thanks, that's a much better idea! The bash script was definitely a bit clunky, so I decided to do this inside an RSpec test. I call I was initially using Thanks for the idea, and this is much better! |
@ndbroadbent Just curious, if it's a problem with Sidekiq configuration isn't it easier to cover it with unit test? |
@Tensho This was coming from But I do think that this kind of end-to-end integration test is really useful, so you can be sure that the worker is able to boot and process a job from a real Redis connection. I do the same thing for puma, to make sure that my Docker images can boot the Rails server and pass a simple health check by rendering a Rails view. This has also been a really helpful safety guard. |
IME people using
-d
to daemonize almost always don't know the "proper" way to supervise and control Sidekiq or other long-running services. I'd like to remove the-d
,-P
and-L
CLI arguments as they are Unix legacy and we need to entice users to learn the newer, better ways.Please chime in if you have a use case this might break.
The text was updated successfully, but these errors were encountered: