mongrel unicorn - Dec 2009 - Listening UNIX socket is not deleted when stopping Unicorn?

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

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

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

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

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

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

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

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