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

Remove the daemonize feature #378

Merged
merged 1 commit into from
Oct 8, 2023
Merged

Remove the daemonize feature #378

merged 1 commit into from
Oct 8, 2023

Conversation

olleolleolle
Copy link
Member

@olleolleolle olleolleolle commented Oct 7, 2023

Description:

This is a Pull Request which removes the --daemonize option, its documentation, and all related mentions.

Puma no longer supports it. There are new, other ways to do that.

This closes #359 with a more-final change.

Perhaps this means that there we may need new ways of enabling a Puma::CommonLogger, of enabling non-stdout output (that is "setup_logger") in the Gemstash server.

Now, gemstash operates "in front, in the terminal it is started".

I will abide by the code of conduct.

@simi
Copy link
Member

simi commented Oct 7, 2023

Looks good to me, any plan on release? Minor/major bump needed?

@olleolleolle
Copy link
Member Author

@simi I could do a full 3.0 major bump for this, it's fine. One could argue for a minor bump since the de-facto drop of this feature was done when we began relying on a Puma 6 that had dropped it (I think in the Puma 6 major --daemonize was removed).

(https://github.com/kigster/puma-daemon#41-using-config-file has good descriptions of what a daemonize solution could look like, now.)

@th1agoalmeida
Copy link
Contributor

Awesome! 💯

@cli.say("Starting gemstash!", :green)
Puma::CLI.new(args, Gemstash::Logging::StreamLogger.puma_events).run
end

private

def setup_logging
return unless daemonize?

# Enables logging at all times, perhaps there needs to be a new option for this?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code comment is about "Does the CLI need an option like --run-in-foreground to not redirect the log output into a file?"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this uses "logger in a signal handler"

Compare this comment, and see how it refers to a nice closure trick from Sidekiq:
resque/resque#1493 (comment)

By removing code which depended on the daemonize?, I got the expected working behaviour.

@olleolleolle olleolleolle marked this pull request as ready for review October 8, 2023 17:30
@olleolleolle olleolleolle force-pushed the cli_daemonized_false branch 2 times, most recently from 07474ff to e938bdc Compare October 8, 2023 17:40
Fixes #359.

Puma 6 no longer supports the --daemonize option.

It is not something we wish to support inside Gemstash.
@olleolleolle olleolleolle merged commit a66162c into main Oct 8, 2023
12 checks passed
@olleolleolle olleolleolle deleted the cli_daemonized_false branch October 8, 2023 18:05
@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

This broke my prod.

@simi I could do a full 3.0 major bump for this, it's fine. One could argue for a minor bump since the de-facto drop of this feature was done when we began relying on a Puma 6 that had dropped it (I think in the Puma 6 major --daemonize was removed).

Feature aside, I was using the --no-daemonize option. With the removal of that option, gemstash crashed when I upgraded it. Please consider making the CLI args public API, and incorporate it into your versioning scheme. This could have been done in a backward-compatible manner if desired, e.g. by emitting a warning about this option no longer doing anything instead of removing it entirely.

(edit: I originally made a typo and said I was using --daemonize, my apologies)

@simi
Copy link
Member

simi commented Oct 10, 2023

@kyrofa that feature was removed in Puma at version 6 and got broken at 14eac03 in gemstash. In last version we just removed that already broken option. Sorry to hear this broke your environment.

@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

@simi my understanding is not that --no-daemonize broke, but that it became the default behavior, correct? That changed nothing for me: I didn't even notice. But removal of the CLI option did indeed cause breakage.

I think we can agree that 4eac03937e83db6db6365ffdc1fd86b990b8ebf probably should have been a major version bump due to the behavior change. 20/20 hindsight, as they say. But are we really using that arguable mistake to justify putting more breakage in the same major release?

@simi
Copy link
Member

simi commented Oct 10, 2023

@simi my understanding is not that --no-daemonize broke, but that it became the default behavior, correct? That changed nothing for me: I didn't even notice. But removal of the CLI option did indeed cause breakage.

Ahh, clear. a66162c#diff-1b2a427dbe98191af04a96ffbfe65d744487281f99dfc8bd6a21de087cb9de72L78-L79 I think we have missed by removing --daemonize also --no-daemonize was removed and that could potentially cause troubles.

Do you think it is worth it to release new version adding back this option back in deprecated manner?

@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

Do you think it is worth it to release new version adding back this option back in deprecated manner?

I think that would probably be appreciated by other folks using this option. It gives them a chance to understand why these things were removed and update their usage without breaking them. I understand it's more work, of course, and to be clear I've fixed this on my end. Think about it!

@simi
Copy link
Member

simi commented Oct 10, 2023

Do you think it is worth it to release new version adding back this option back in deprecated manner?

I think that would probably be appreciated by other folks using this option. It gives them a chance to understand why these things were removed and update their usage without breaking them.

Clear, let us create the update.

The idea behind this was --daemonize doesn't work anymore and by removing it we don't break any setup (since it doesn't work anyway). But since --no-daemonize is automatically created by thor cli DSL, we have missed that is going to be removed as well as currently valid option causing no troubles and that could cause these issues. 😞

@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

Ohhhhhhh I totally missed that the inverse option was created automatically. That makes WAY more sense. That said, turning --daemonize from "I'm not behaving the way you want" to crashing is still a second round of breakage (where the first round was initially making --daemonize not behave properly). My two cents.

@simi
Copy link
Member

simi commented Oct 10, 2023

Ohhhhhhh I totally missed that the inverse option was created automatically. That makes WAY more sense. That said, turning --daemonize from "I'm not behaving the way you want" to crashing is still a second round of breakage (where the first round was initially making --daemonize not behave properly). My two cents.

--daemonize wasn't "I'm not behaving the way you want", but crashing already in 2.6.x

[retro@retro  ps5]❤ bundle exec gemstash start --daemonize
Starting gemstash!
bundler: failed to load command: gemstash (/home/retro/.gem/ruby/3.2.2/bin/gemstash)
/home/retro/.gem/ruby/3.2.2/gems/puma-6.4.0/lib/puma/cli.rb:45:in `initialize': invalid option: --daemon (OptionParser::InvalidOption)
        from /home/retro/.gem/ruby/3.2.2/gems/gemstash-2.6.0/lib/gemstash/cli/start.rb:16:in `new'
        from /home/retro/.gem/ruby/3.2.2/gems/gemstash-2.6.0/lib/gemstash/cli/start.rb:16:in `run'
        from /home/retro/.gem/ruby/3.2.2/gems/gemstash-2.6.0/lib/gemstash/cli.rb:83:in `start'
        from /home/retro/.gem/ruby/3.2.2/gems/thor-1.2.2/lib/thor/command.rb:27:in `run'
        from /home/retro/.gem/ruby/3.2.2/gems/thor-1.2.2/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/retro/.gem/ruby/3.2.2/gems/thor-1.2.2/lib/thor.rb:392:in `dispatch'
        from /home/retro/.gem/ruby/3.2.2/gems/thor-1.2.2/lib/thor/base.rb:485:in `start'
        from /home/retro/.gem/ruby/3.2.2/gems/gemstash-2.6.0/lib/gemstash/cli.rb:34:in `start'
        from /home/retro/.gem/ruby/3.2.2/gems/gemstash-2.6.0/exe/gemstash:6:in `<top (required)>'
        from /home/retro/.gem/ruby/3.2.2/bin/gemstash:25:in `load'
        from /home/retro/.gem/ruby/3.2.2/bin/gemstash:25:in `<top (required)>'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:58:in `load'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:58:in `kernel_load'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli/exec.rb:23:in `run'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:492:in `exec'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:34:in `dispatch'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/cli.rb:28:in `start'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.5.0.dev/exe/bundle:37:in `block in <top (required)>'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/site_ruby/3.2.0/bundler/friendly_errors.rb:117:in `with_friendly_errors'
        from /home/retro/.rubies/ruby-3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.5.0.dev/exe/bundle:29:in `<top (required)>'
        from /home/retro/.gem/ruby/3.2.2/bin/bundle:25:in `load'
        from /home/retro/.gem/ruby/3.2.2/bin/bundle:25:in `<main>'

@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

Ah, then I am mistaken indeed, and I understand where you're coming from now. Thank you for your patience!

@simi
Copy link
Member

simi commented Oct 10, 2023

Ah, then I am mistaken indeed, and I understand where you're coming from now. Thank you for your patience!

Thanks for you patience as well, let's release the 2.7.1 soon adding back no-op --no-daemonize with warning.

@kyrofa
Copy link
Contributor

kyrofa commented Oct 10, 2023

Thank you @simi 🤗

@simi
Copy link
Member

simi commented Oct 12, 2023

@kyrofa 0f8e2ab 💪

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

Successfully merging this pull request may close these issues.

Drop --daemonize which is not supported by stock Puma
4 participants