Re: Suggestion for reload action (USR2)

Re: Suggestion for reload action (USR2)

[Iñaki Baz Castillo]

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@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Suggestion for reload action (USR2)

[Eric Wong]

Iñaki Baz Castillo <ibc@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
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Suggestion for reload action (USR2)

[Iñaki Baz Castillo]

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
> process

Great, 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@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Suggestion for reload action (USR2)

[Eric Wong]

Iñaki Baz Castillo <ibc@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
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Re: Suggestion for reload action (USR2)

[Iñaki Baz Castillo]

El Miércoles, 20 de Enero de 2010, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@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@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying

Suggestion for reload action (USR2)

[Iñaki Baz Castillo]

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@aliax.net>
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying