Re: graceful restart under runit

["Dražen Kačar" <dave@fly.srk.fer.hr>]

Paul Jarc wrote:
> Dražen Kačar <dave@fly.srk.fer.hr> wrote:
> > Paul Jarc wrote:
> >> Also, using a socket means you have two-way communication, so you
> >> don't need signals or PID files, which are subject to race conditions.
> >
> > Files maybe are, but signals?
> 
> Unless you're sending signals to your own child process, there's a
> chance that the process you're signaling has already died, and its PID
> has been reused for a new process.  This is true no matter how you
> obtain the PID to send signals to; PID files are just one case of
> that.  The only exception is for the parent, which knows that the
> child's PID hasn't been recycled because, even if the child has
> exited, the parent hasn't wait()ed for the child yet.

Ah, that. Well, you'd just have to rely on the usually-not-documented OS
feature. PIDs are not recycled fast in practice, so that would have to be
good enough.

Somewhat unportable guarantee could be obtained via /proc.  You know the
PID, so you stop the process via /proc or ptrace() or whatever is
available for debuggers (something will be available), check that the PID
is associated with the correct executable via /proc, send your signal (now
the process won't go away) and then detach from the process.

Checking whether the PID corresponds to the correct executable is the
messy part and I don't know if it can be handled in a reasonable way for
this purpose.

I'd just live with the race condition and rely on the OS not to reuse PIDs
too fast.

> > A server binds to the file system socket after it got the network socket,
> > either by a direct bind() or by a passover from an existing server. That
> > should be enough, I think. It's not atomic, but it's a locking protocol.
> 
> Actually, obtaining the network socket can be atomic enough - bind()

I meant for the whole thing: obtain the network socket and then obtain the
file system socket. Mandating that the network socket must be obtained
first and file system socket second is a locking protocol. And the first
lock in the locking protocol must be atomic.

> So I guess there's no big advantage either way between the metaserver
> vs. keeping all the handoff functionality in one program.

Unless LD_PRELOAD method can work. Then the metaserver has a distinct
advantage for those who need it.

> > That's a good one. But shouldn't that mask the bind() function?
> 
> Probably, but it won't actually work either way, since the server
> needs to notice traffic on the filesystem connection.
> 
> > As for the lease problem, couldn't metaserver just SIGTERM the existing
> > server?
> 
> That suffers from the PID-recycling problem above.

Well, I'd just ignore that problem. Or go through unportable interface for
the debuggers when feeling paranoid.

-- 
 .-.   .-.    Yes, I am an agent of Satan, but my duties are largely
(_  \ /  _)   ceremonial.
     |
     |        dave@fly.srk.fer.hr