PID is not regenerated when using "-P" and the master receives USR2

PID is not regenerated when using "-P" and the master receives USR2

[Iñaki Baz Castillo]

In case of using "unicorn -P PIDFILE" when the master receives a USR2 the 
pidfile is deleted and not regenerated anymore.

In case of using "pid" mehotd in config file then it works well.

It seems a bug, do I miss something?

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: PID is not regenerated when using "-P" and the master receives USR2

[Iñaki Baz Castillo]

El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> In case of using "unicorn -P PIDFILE" when the master receives a USR2 the
> pidfile is deleted and not regenerated anymore.
> 
> In case of using "pid" mehotd in config file then it works well.
> 
> It seems a bug, do I miss something?

Definitively I think this is the expected behaviour as the new binary has no 
way to know the PIDFILE passed as commandline argument to original binary, am 
I right?

-- 
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: PID is not regenerated when using "-P" and the master receives USR2

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > In case of using "unicorn -P PIDFILE" when the master receives a USR2 the
> > pidfile is deleted and not regenerated anymore.
> > 
> > In case of using "pid" mehotd in config file then it works well.
> > 
> > It seems a bug, do I miss something?
> 
> Definitively I think this is the expected behaviour as the new binary has no 
> way to know the PIDFILE passed as commandline argument to original binary, am 
> I right?

All command-line arguments are passed to the child process.  We capture
the command-line as soon as possible before option parsing happens.

When USR2 is received, we create a new pid file for the old
binary and add the ".oldbin" suffix to the pathname.

That said, "-P" in the command-line and "pid" in the config file should
work the same.  Despite being officially deprecated, "-P" is used
extensively and interchangeably with "pid" in the existing tests.

-- 
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: PID is not regenerated when using "-P" and the master receives USR2

[Iñaki Baz Castillo]

El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > > In case of using "unicorn -P PIDFILE" when the master receives a USR2
> > > the pidfile is deleted and not regenerated anymore.
> > >
> > > In case of using "pid" mehotd in config file then it works well.
> > >
> > > It seems a bug, do I miss something?
> >
> > Definitively I think this is the expected behaviour as the new binary has
> > no way to know the PIDFILE passed as commandline argument to original
> > binary, am I right?
> 
> All command-line arguments are passed to the child process.  We capture
> the command-line as soon as possible before option parsing happens.
> 
> When USR2 is received, we create a new pid file for the old
> binary and add the ".oldbin" suffix to the pathname.
> 
> That said, "-P" in the command-line and "pid" in the config file should
> work the same.  Despite being officially deprecated, "-P" is used
> extensively and interchangeably with "pid" in the existing tests.

Yes, I confirm that using pure "unicorn" command with "-P" it works (both 
"name.pid" and "name.pid.oldbin" exist after USR2).

However I use a modified version of "unicorn" executable, which is the same 
with just two differences:

- The name is different.

- The commandline "-c" and "rackup" are removed. Instead these values are 
fixed and I set them into the executable script by adding:

  options[:config_file]  = "PATH_TO_UNICORN_CONFIG.rb"
  config                 = "PATH_TO_CONFIG.ru"


So to run as daemon I just type:

  ~# myapp -D -P /tmp/myapp.pid


Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I 
don't see a new "/tmp/myapp.pid".


Thanks a lot for your help.


-- 
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: PID is not regenerated when using "-P" and the master receives USR2

[Iñaki Baz Castillo]

El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > > > In case of using "unicorn -P PIDFILE" when the master receives a USR2
> > > > the pidfile is deleted and not regenerated anymore.
> > > >
> > > > In case of using "pid" mehotd in config file then it works well.
> > > >
> > > > It seems a bug, do I miss something?
> > >
> > > Definitively I think this is the expected behaviour as the new binary
> > > has no way to know the PIDFILE passed as commandline argument to
> > > original binary, am I right?
> >
> > All command-line arguments are passed to the child process.  We capture
> > the command-line as soon as possible before option parsing happens.
> >
> > When USR2 is received, we create a new pid file for the old
> > binary and add the ".oldbin" suffix to the pathname.
> >
> > That said, "-P" in the command-line and "pid" in the config file should
> > work the same.  Despite being officially deprecated, "-P" is used
> > extensively and interchangeably with "pid" in the existing tests.
> 
> Yes, I confirm that using pure "unicorn" command with "-P" it works (both
> "name.pid" and "name.pid.oldbin" exist after USR2).
> 
> However I use a modified version of "unicorn" executable, which is the same
> with just two differences:
> 
> - The name is different.
> 
> - The commandline "-c" and "rackup" are removed. Instead these values are
> fixed and I set them into the executable script by adding:
> 
>   options[:config_file]  = "PATH_TO_UNICORN_CONFIG.rb"
>   config                 = "PATH_TO_CONFIG.ru"
> 
> 
> So to run as daemon I just type:
> 
>   ~# myapp -D -P /tmp/myapp.pid
> 
> 
> Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I
> don't see a new "/tmp/myapp.pid".
> 
> 
> Thanks a lot for your help.


I've some issue somewhere as when sending the USR2 I see:

  INFO: executing ["/usr/local/bin/myapp"] (in /)

while it should be ["/usr/local/bin/myapp","-P","/tmp/myapp.pid","-D"]


-- 
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: PID is not regenerated when using "-P" and the master receives USR2

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> > El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> > > Iñaki Baz Castillo <ibc@aliax.net> wrote:
> > > > El Jueves, 31 de Diciembre de 2009, Iñaki Baz Castillo escribió:

<snip>

> > > All command-line arguments are passed to the child process.  We capture
> > > the command-line as soon as possible before option parsing happens.
> > 
> > However I use a modified version of "unicorn" executable, which is the same
> > with just two differences:
> > 
> > - The name is different.
> > 
> > - The commandline "-c" and "rackup" are removed. Instead these values are
> > fixed and I set them into the executable script by adding:
> > 
> >   options[:config_file]  = "PATH_TO_UNICORN_CONFIG.rb"
> >   config                 = "PATH_TO_CONFIG.ru"
> > 
> > 
> > So to run as daemon I just type:
> > 
> >   ~# myapp -D -P /tmp/myapp.pid
> > 
> > 
> > Could it explain my issue? I see "/tmp/myapp.pid.oldbin" after USR2, but I
> > don't see a new "/tmp/myapp.pid".
> > 
> > 
> > Thanks a lot for your help.
> 
> 
> I've some issue somewhere as when sending the USR2 I see:
> 
>   INFO: executing ["/usr/local/bin/myapp"] (in /)
> 
> while it should be ["/usr/local/bin/myapp","-P","/tmp/myapp.pid","-D"]

You need to require 'unicorn/launcher' or 'unicorn' before you do any
option parsing to stash ARGV in a safe place.

You can also play with the Unicorn::HttpServer::START_CTX hash
and modify the :argv array value if needed...

-- 
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: PID is not regenerated when using "-P" and the master receives USR2

[Iñaki Baz Castillo]

El Jueves, 31 de Diciembre de 2009, Eric Wong escribió:
> You need to require 'unicorn/launcher' or 'unicorn' before you do any
> option parsing to stash ARGV in a safe place.

Thanks, that was the point.
In my script I load unicorn/launcher after args parsing so ARGV gets empty.

Thanks. 


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