Hi, when Unicorn receives a USR2 it invokes the original script and arguments and creates a new master as a child. However when running this new master there could be something to treat different as when we run Unicorn for first time. For example: - In the initial unicorn master I want it to create a Posix_mq, and in case it already exists then I want it to delete and create again. - But in the new master (when USR2) I just want it to reuse the existing Posiq_mq. Note this is just an example, perhaps not the best however. So I suggest the following: - When unicorn master receives a USR2 it executes the original executable withthe original arguments plus "--reload". This just would mean that the new instance is a reloaded process. The executable could store such option somewhere so the application could know it and react. This would involve just three changes: - Add an option "--reload" in OptionParser in bin/unicorn. - Store such option somewhere so it can be readed later by the Rack application or other library. - Add "--reload" to the list of original arguments when receiving USR2. Opinnions? -- I?aki Baz Castillo <ibc at aliax.net>
El Mi?rcoles, 20 de Enero de 2010, I?aki Baz Castillo escribi?:> This would involve just three changes: > > - Add an option "--reload" in OptionParser in bin/unicorn. > - Store such option somewhere so it can be readed later by the Rack > application or other library. > - Add "--reload" to the list of original arguments when receiving USR2.I attach a patch (for master branch) that would do the job (except the fact that I don''t know how to store the "reload" option): ----------------------------------------- diff --git a/bin/unicorn b/bin/unicorn index 5af021d..43f5434 100755 --- a/bin/unicorn +++ b/bin/unicorn @@ -88,6 +88,10 @@ opts = OptionParser.new("", 24, '' '') do |opts| options[:config_file] = f end + opts.on("--reload", "HIDDEN") do |f| + # TODO: Store it somewhere + end + # I''m avoiding Unicorn-specific config options on the command-line. # IMNSHO, config options on the command-line are redundant given # config files and make things unnecessarily complicated with multiple @@ -96,7 +100,7 @@ opts = OptionParser.new("", 24, '' '') do |opts| opts.separator "Common options:" opts.on_tail("-h", "--help", "Show this message") do - puts opts.to_s.gsub(/^.*DEPRECATED.*$/s, '''') + puts opts.to_s.gsub(/^.*DEPRECATED.*$/s, '''').gsub(/^.*HIDDEN.*$/s, '''') exit end diff --git a/lib/unicorn.rb b/lib/unicorn.rb index e3e4315..49ad79b 100644 --- a/lib/unicorn.rb +++ b/lib/unicorn.rb @@ -519,7 +519,7 @@ module Unicorn end logger.info "executing #{cmd.inspect} (in #{Dir.pwd})" before_exec.call(self) - exec(*cmd) + exec(*cmd << "--reload") end proc_name ''master (old)'' end ----------------------------------------- The patch is available here: http://oversip.net/public/unicorn_reload.patch (unfortunatelly I cannot attach files in this mailist as the mail is rejected). Regards. -- I?aki Baz Castillo <ibc at aliax.net>
I?aki Baz Castillo <ibc at aliax.net> wrote:> El Mi?rcoles, 20 de Enero de 2010, I?aki Baz Castillo escribi?: > > > This would involve just three changes: > > > > - Add an option "--reload" in OptionParser in bin/unicorn. > > - Store such option somewhere so it can be readed later by the Rack > > application or other library. > > - Add "--reload" to the list of original arguments when receiving USR2.Hi I?aki, All you need to do is to check for the presence of ENV["UNICORN_FD"] which is used to communicate file descriptor numbers for the upgrade process> I attach a patch (for master branch) that would do the job (except the > fact that I don''t know how to store the "reload" option):> (unfortunatelly I cannot attach files in this mailist as the mail is > rejected).While the patch was not needed for this case, inline patches are strongly preferred here. Inline patches are far easier to read, reply-to and apply than attachments. -- Eric Wong
El Mi?rcoles, 20 de Enero de 2010, Eric Wong escribi?:> All you need to do is to check for the presence of ENV["UNICORN_FD"] > which is used to communicate file descriptor numbers for the upgrade > processGreat, I didn''t know it! :)> > I attach a patch (for master branch) that would do the job (except the > > fact that I don''t know how to store the "reload" option): > > > > (unfortunatelly I cannot attach files in this mailist as the mail is > > rejected). > > While the patch was not needed for this case, inline patches are strongly > preferred here. Inline patches are far easier to read, reply-to and > apply than attachments.Sure but what about the fixed 80 columns of a mail? Of course I can generate the mail without such constrain, but it doesn''t look very cool :) Thanks a lot. -- I?aki Baz Castillo <ibc at aliax.net>
I?aki Baz Castillo <ibc at aliax.net> wrote:> El Mi?rcoles, 20 de Enero de 2010, Eric Wong escribi?: > > While the patch was not needed for this case, inline patches are strongly > > preferred here. Inline patches are far easier to read, reply-to and > > apply than attachments. > > Sure but what about the fixed 80 columns of a mail? > Of course I can generate the mail without such constrain, but it doesn''t look > very cool :)For mail, the soft limit is actually closer/around to 72 columns because we take quoting into consideration. But properly configured mailers shouldn''t care nor enforce this (git-send-email(1) does not). http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches has some good notes on various mailers (I usually use mutt to send one-off patches and git send-email for a series). -- Eric Wong
El Mi?rcoles, 20 de Enero de 2010, Eric Wong escribi?:> I?aki Baz Castillo <ibc at aliax.net> wrote: > > El Mi?rcoles, 20 de Enero de 2010, Eric Wong escribi?: > > > While the patch was not needed for this case, inline patches are > > > strongly preferred here. Inline patches are far easier to read, > > > reply-to and apply than attachments. > > > > Sure but what about the fixed 80 columns of a mail? > > Of course I can generate the mail without such constrain, but it doesn''t > > look very cool :) > > For mail, the soft limit is actually closer/around to 72 columns because > we take quoting into consideration. But properly configured mailers > shouldn''t care nor enforce this (git-send-email(1) does not). > > http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatch > es has some good notes on various mailers (I usually use mutt to send > one-off patches and git send-email for a series). >KMail ----- This should help you to submit patches inline using KMail. 1) Prepare the patch as a text file. 2) Click on New Mail. 3) Go under "Options" in the Composer window and be sure that "Word wrap" is not set. 4) Use Message -> Insert file... and insert the patch. 5) Back in the compose window: add whatever other text you wish to the 514 message, complete the addressing and subject fields, and press send. :) -- I?aki Baz Castillo <ibc at aliax.net>