Re: Pidfiles and cwd?

Re: Pidfiles and cwd?

[Chris Wanstrath]

Yikes. Let me try that again.

Hi,

Thanks for unicorn!

Two questions:

A) Is there a reason `unicorn` allows you to specify the pidfile's
location but `unicorn_rails` does not?

B) Is there a reason `unicorn_rails` must start in the app root and
doesn't allow it as a config option?

Thanks,

Chris

On Fri, Sep 4, 2009 at 8:20 PM, Chris Wanstrath <chris@ozmm.org> wrote:
>
> Hi,
> Thanks for unicorn!
> Two questions:
> A) Is there a reason `unicorn` allows you to specify the pidfile's location but `unicorn_rails
>
> --
> Chris Wanstrath
> http://github.com/defunkt



--
Chris Wanstrath
http://github.com/defunkt

Re: Pidfiles and cwd?

[Eric Wong]

Chris Wanstrath <chris@ozmm.org> wrote:
> Yikes. Let me try that again.
> 
> Hi,
> 
> Thanks for unicorn!

Hi Chris, no problem!

> Two questions:
> 
> A) Is there a reason `unicorn` allows you to specify the pidfile's
> location but `unicorn_rails` does not?

`unicorn` was designed to mimic `rackup` in terms of command line
options and `unicorn_rails` was designed to mimic `script/server` in
Rails.

I really didn't know what I was doing with the command-line options for
this, so I decided to steal from others :)

For long-running servers, I'm not a fan of command-line options in
general because they're easy to forget, so `unicorn` only supports it
because `rackup` does it (so the embedded CLI options in config.ru can
be shared).

For `unicorn_rails`, --daemonize already sets a default PID path in
RAILS_ROOT/tmp/pids/unicorn.pid whereas `script/server` chooses
RAILS_ROOT/tmp/pids/server.pid.  Since Rails values "convention over
configuration",  I figured I might as well hard code it...

Additionally, the "-P" parameter used by unicorn_rails and script/server
is used to set RAILS_RELATIVE_URL_ROOT so it conflicts with the short
option used by rackup/unicorn.

> B) Is there a reason `unicorn_rails` must start in the app root and
> doesn't allow it as a config option?

Since the config file is just Ruby, you can just Dir.chdir inside it.
And since the chdir is done when the config file is evaluated, the
chdir can be done across restarts/reloads (you can point it to a
symlinked directory) to pick up new code/releases.

If you do that, I would initially start Unicorn in "/" or some other
directory that won't get deleted so you'll be safe for upgrades.

If you managed to forget that, you can set the following in your
Unicorn config:

  Unicorn::HttpServer::START_CTX[:cwd] = "/"

And then HUP the process before doing the USR2+QUIT to reexec.
Subsequent Unicorns will always start in "/" and then you can
Dir.chdir to wherever you run your app.

Hopefully that makes sense, one thing I've been trying to avoid with the
configuration is having too many ways to do the same thing.

-- 
Eric Wong

Re: Pidfiles and cwd?

[Eric Wong]

Eric Wong <normalperson@yhbt.net> wrote:
> > B) Is there a reason `unicorn_rails` must start in the app root and
> > doesn't allow it as a config option?
> 
> Since the config file is just Ruby, you can just Dir.chdir inside it.
> And since the chdir is done when the config file is evaluated, the
> chdir can be done across restarts/reloads (you can point it to a
> symlinked directory) to pick up new code/releases.
> 
> If you do that, I would initially start Unicorn in "/" or some other
> directory that won't get deleted so you'll be safe for upgrades.
> 
> If you managed to forget that, you can set the following in your
> Unicorn config:
> 
>   Unicorn::HttpServer::START_CTX[:cwd] = "/"

Maybe having a 'working_directory "/path/to/app/root"' that does:

  Dir.chdir(Unicorn::HttpServer::START_CTX[:cwd] = arg)

Internally would make things easier?

I see nginx has a "working_directory" config option as well:
  http://wiki.nginx.org/NginxHttpMainModule

-- 
Eric Wong

Re: Pidfiles and cwd?

[Chris Wanstrath]

On Fri, Sep 4, 2009 at 9:28 PM, Eric Wong<normalperson@yhbt.net> wrote:

>> A) Is there a reason `unicorn` allows you to specify the pidfile's
>> location but `unicorn_rails` does not?
>
> `unicorn` was designed to mimic `rackup` in terms of command line
> options and `unicorn_rails` was designed to mimic `script/server` in
> Rails.
>
> I really didn't know what I was doing with the command-line options for
> this, so I decided to steal from others :)
>
> For long-running servers, I'm not a fan of command-line options in
> general because they're easy to forget, so `unicorn` only supports it
> because `rackup` does it (so the embedded CLI options in config.ru can
> be shared).
>
> For `unicorn_rails`, --daemonize already sets a default PID path in
> RAILS_ROOT/tmp/pids/unicorn.pid whereas `script/server` chooses
> RAILS_ROOT/tmp/pids/server.pid.  Since Rails values "convention over
> configuration",  I figured I might as well hard code it...
>
> Additionally, the "-P" parameter used by unicorn_rails and script/server
> is used to set RAILS_RELATIVE_URL_ROOT so it conflicts with the short
> option used by rackup/unicorn.

I'm 100% on board with your reasoning here, but I don't understand why
we can't set the pid in the config file. Am I reading this wrong?
(Very possibly.)

Doesn't this line mean that any `pid` setting in the configurator is ignored:

http://git.bogomips.org/cgit/unicorn.git/tree/lib/unicorn.rb#n83

If so, how would you suggest setting the pid at runtime? I don't mean
to be difficult, we just want to keep everything in /var/run

>> B) Is there a reason `unicorn_rails` must start in the app root and
>> doesn't allow it as a config option?
>
> Since the config file is just Ruby, you can just Dir.chdir inside it.
> And since the chdir is done when the config file is evaluated, the
> chdir can be done across restarts/reloads (you can point it to a
> symlinked directory) to pick up new code/releases.
>
> If you do that, I would initially start Unicorn in "/" or some other
> directory that won't get deleted so you'll be safe for upgrades.
>
> If you managed to forget that, you can set the following in your
> Unicorn config:
>
>  Unicorn::HttpServer::START_CTX[:cwd] = "/"
>
> And then HUP the process before doing the USR2+QUIT to reexec.
> Subsequent Unicorns will always start in "/" and then you can
> Dir.chdir to wherever you run your app.
>
> Hopefully that makes sense, one thing I've been trying to avoid with the
> configuration is having too many ways to do the same thing.

Sounds good to me. Unicorn has quite completely convinced me that
pure-Ruby config files are the way to go. I've already done some crazy
stuff in there during our migration that a YAML file (or whatever)
just wouldn't have been able to handle.

Cheers,

-- 
Chris Wanstrath
http://github.com/defunkt

Re: Pidfiles and cwd?

[Eric Wong]

Chris Wanstrath <chris@ozmm.org> wrote:
> On Fri, Sep 4, 2009 at 9:28 PM, Eric Wong<normalperson@yhbt.net> wrote:
> 
> >> A) Is there a reason `unicorn` allows you to specify the pidfile's
> >> location but `unicorn_rails` does not?
> >
> > `unicorn` was designed to mimic `rackup` in terms of command line
> > options and `unicorn_rails` was designed to mimic `script/server` in
> > Rails.
> >
> > I really didn't know what I was doing with the command-line options for
> > this, so I decided to steal from others :)
> >
> > For long-running servers, I'm not a fan of command-line options in
> > general because they're easy to forget, so `unicorn` only supports it
> > because `rackup` does it (so the embedded CLI options in config.ru can
> > be shared).
> >
> > For `unicorn_rails`, --daemonize already sets a default PID path in
> > RAILS_ROOT/tmp/pids/unicorn.pid whereas `script/server` chooses
> > RAILS_ROOT/tmp/pids/server.pid.  Since Rails values "convention over
> > configuration",  I figured I might as well hard code it...
> >
> > Additionally, the "-P" parameter used by unicorn_rails and script/server
> > is used to set RAILS_RELATIVE_URL_ROOT so it conflicts with the short
> > option used by rackup/unicorn.
> 
> I'm 100% on board with your reasoning here, but I don't understand why
> we can't set the pid in the config file. Am I reading this wrong?
> (Very possibly.)

You can definitely set the pid in the config file, let me know
if you're having issues...

> Doesn't this line mean that any `pid` setting in the configurator is ignored:
> 
> http://git.bogomips.org/cgit/unicorn.git/tree/lib/unicorn.rb#n83

It's only ignored at that time, the pid is dropped later in the start
method:

http://git.bogomips.org/cgit/unicorn.git/tree/lib/unicorn.rb#n114

	self.pid = config[:pid]

So I don't drop the pid file until listeners are bound.  I can't
remember why I drop the pid late, however :)

I know I don't bind the listeners right away because I try inheriting
them first.  It might be to avoid issues with the pid clobbering in the
parent, or that some health checkers rely on both the pid and listen
socket or something...

> If so, how would you suggest setting the pid at runtime? I don't mean
> to be difficult, we just want to keep everything in /var/run

The config file really should work, but be sure to let me know if it's
still not working for you.  I just tested unicorn_rails with a test app
and it seems to work here.  Perhaps you're hitting permissions problems?

As far as permissions, I'm considering adding user switching, but I'm
afraid it could lead to more problems/support issues since I don't know
anybody who runs Mongrel/Thin as root.  However I've already
written a huge comment/example in the Configurator RDoc for it :)

> >> B) Is there a reason `unicorn_rails` must start in the app root and
> >> doesn't allow it as a config option?
> >
> > Since the config file is just Ruby, you can just Dir.chdir inside it.
> > And since the chdir is done when the config file is evaluated, the
> > chdir can be done across restarts/reloads (you can point it to a
> > symlinked directory) to pick up new code/releases.
> >
> > If you do that, I would initially start Unicorn in "/" or some other
> > directory that won't get deleted so you'll be safe for upgrades.
> >
> > If you managed to forget that, you can set the following in your
> > Unicorn config:
> >
> >  Unicorn::HttpServer::START_CTX[:cwd] = "/"
> >
> > And then HUP the process before doing the USR2+QUIT to reexec.
> > Subsequent Unicorns will always start in "/" and then you can
> > Dir.chdir to wherever you run your app.
> >
> > Hopefully that makes sense, one thing I've been trying to avoid with the
> > configuration is having too many ways to do the same thing.
> 
> Sounds good to me. Unicorn has quite completely convinced me that
> pure-Ruby config files are the way to go. I've already done some crazy
> stuff in there during our migration that a YAML file (or whatever)
> just wouldn't have been able to handle.

Cool, thanks for the feedback.

I've had lots of issues dealing with ugly/limited config files and seen
too many ways of templating them to count.  The after_fork, before_fork,
and before_exec hooks sealed the deal for Ruby and Ezra / Rack::Builder
helped push me in the right direction with the DSL.  It was originally
"write a small ruby script to run this thing" :)

-- 
Eric Wong