Listening UNIX socket is not deleted when stopping Unicorn?

Listening UNIX socket is not deleted when stopping Unicorn?

[Iñaki Baz Castillo]

Hi, I listen into an UNIX socket but after stopping Unicorn the socket is not 
removed. Is it the expected behavior?

This causes problem of permissions when changing the user/group running the 
workers (as they cannot remove the old socket with different owner).

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: Listening UNIX socket is not deleted when stopping Unicorn?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> Hi, I listen into an UNIX socket but after stopping Unicorn the socket
> is not removed. Is it the expected behavior?

Yes.

Otherwise it's subject to race conditions where the socket
owned by a new/replacement process gets its socket unlinked.

Currently Unicorn unlinks any existing socket on the FS before
attempting to bind to it for the following reasons:

* I consider this less error-prone, especially when people aren't
  storing sockets in a directory that's cleared on reboots (like /tmp).

* This can also be desirable behavior since it can be used to do
  transparent upgrades/binary replacements in cases where it's less
  convenient to use USR2+QUIT,  if you're switching between Ruby
  installations for example.

> This causes problem of permissions when changing the user/group
> running the workers (as they cannot remove the old socket with
> different owner).

Since there's absolutely no point in running Unicorn on port 80/443, you
should just avoid user switching entirely since it'll significantly
simplify your setup(s).

-- 
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: Listening UNIX socket is not deleted when stopping Unicorn?

[Iñaki Baz Castillo]

El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> Otherwise it's subject to race conditions where the socket
> owned by a new/replacement process gets its socket unlinked.
> 
> Currently Unicorn unlinks any existing socket on the FS before
> attempting to bind to it for the following reasons:
> 
> * I consider this less error-prone, especially when people aren't
>   storing sockets in a directory that's cleared on reboots (like /tmp).
> 
> * This can also be desirable behavior since it can be used to do
>   transparent upgrades/binary replacements in cases where it's less
>   convenient to use USR2+QUIT,  if you're switching between Ruby
>   installations for example.


ok, understood. 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

Re: Listening UNIX socket is not deleted when stopping Unicorn?

[Iñaki Baz Castillo]

El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> Since there's absolutely no point in running Unicorn on port 80/443, you
> should just avoid user switching entirely since it'll significantly
> simplify your setup(s).

The problem are init scripts as they are executed by init process (as root).
There are some ways to run a commandwith other user (as "su") but AFAIK most 
of the servers implement full user switching (not just worker processes) by 
themself.

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: Listening UNIX socket is not deleted when stopping Unicorn?

[Iñaki Baz Castillo]

El Lunes, 28 de Diciembre de 2009, Iñaki Baz Castillo escribió:
> El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> > Since there's absolutely no point in running Unicorn on port 80/443, you
> > should just avoid user switching entirely since it'll significantly
> > simplify your setup(s).
> 
> The problem are init scripts as they are executed by init process (as
>  root). There are some ways to run a commandwith other user (as "su") but
>  AFAIK most of the servers implement full user switching (not just worker
>  processes) by themself.

I've found this workaround by adding the following (extracted from 
Worker#user) at the top of unicorn.conf.rb:

if Process.euid == 0 && (user = MyApp::Config[:user])
  group = MyApp::Config[:group]
  uid = Etc.getpwnam(user).uid
  gid = Etc.getgrnam(group).gid if group
  if gid && Process.egid != gid
    Process.initgroups(user, gid)
    Process::GID.change_privilege(gid)
  end
  Process.euid != uid and Process::UID.change_privilege(uid)
end

Of course using it a worker cannot listen in port <= 1024, but as you said, 
what's the problem with that? :)

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: Listening UNIX socket is not deleted when stopping Unicorn?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> > Since there's absolutely no point in running Unicorn on port 80/443, you
> > should just avoid user switching entirely since it'll significantly
> > simplify your setup(s).
> 
> The problem are init scripts as they are executed by init process (as root).
> There are some ways to run a commandwith other user (as "su") but AFAIK most 
> of the servers implement full user switching (not just worker processes) by 
> themself.

Hi Iñaki,

User switching in the master isn't possible because we need to support
USR2 upgrades (and even some/most cases of HUP/USR1 handling).

But yes, just use su to become a regular user in an init script.

Since you're using a Linux box, maybe you can try getting something with
capabilities and enabling CAP_NET_BIND_SERVICE somehow... I never took
the time to get that working right.

-- 
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: Listening UNIX socket is not deleted when stopping Unicorn?

[Iñaki Baz Castillo]

El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> > Hi, I listen into an UNIX socket but after stopping Unicorn the socket
> > is not removed. Is it the expected behavior?
> 
> Yes.
> 
> Otherwise it's subject to race conditions where the socket
> owned by a new/replacement process gets its socket unlinked.
> 
> Currently Unicorn unlinks any existing socket on the FS before
> attempting to bind to it for the following reasons:
> 
> * I consider this less error-prone, especially when people aren't
>   storing sockets in a directory that's cleared on reboots (like /tmp).
> 
> * This can also be desirable behavior since it can be used to do
>   transparent upgrades/binary replacements in cases where it's less
>   convenient to use USR2+QUIT,  if you're switching between Ruby
>   installations for example.

Hi, just a question:

Then is it totaly safe to delete the socket before starting Unicorn? 
I expect the answer is yes as Unicorn does it.

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

Re: Listening UNIX socket is not deleted when stopping Unicorn?

[Eric Wong]

Iñaki Baz Castillo <ibc@aliax.net> wrote:
> El Lunes, 28 de Diciembre de 2009, Eric Wong escribió:
> > > Hi, I listen into an UNIX socket but after stopping Unicorn the socket
> > > is not removed. Is it the expected behavior?
> > 
> > Yes.
> > 
> > Otherwise it's subject to race conditions where the socket
> > owned by a new/replacement process gets its socket unlinked.
> > 
> > Currently Unicorn unlinks any existing socket on the FS before
> > attempting to bind to it for the following reasons:
> > 
> > * I consider this less error-prone, especially when people aren't
> >   storing sockets in a directory that's cleared on reboots (like /tmp).
> > 
> > * This can also be desirable behavior since it can be used to do
> >   transparent upgrades/binary replacements in cases where it's less
> >   convenient to use USR2+QUIT,  if you're switching between Ruby
> >   installations for example.
> 
> Hi, just a question:
> 
> Then is it totaly safe to delete the socket before starting Unicorn? 
> I expect the answer is yes as Unicorn does it.

Yes.

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