mongrel unicorn - Dec 2009 - PID is not regenerated when using "-P" and the master receives USR2

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 at aliax.net>

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 at aliax.net>

I?aki Baz Castillo <ibc at 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

El Jueves, 31 de Diciembre de 2009, Eric Wong escribi?:
> I?aki Baz Castillo <ibc at 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 at aliax.net>

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 at 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 at aliax.net>

I?aki Baz Castillo <ibc at 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 at 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

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 at aliax.net>