Re: pid file handling issue

From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: pid file handling issue
Date: Thu, 24 Oct 2013 20:27:08 +0000	[thread overview]
Message-ID: <20131024202708.GA4738@dcvr.yhbt.net> (raw)
In-Reply-To: <CABHxtY4ax=yzCL-tEvad9LZw13CYiewhP0jy5vvQWy5vQOqaXw@mail.gmail.com>

Michael Fischer <mfischer@zendesk.com> wrote:
> On Thu, Oct 24, 2013 at 11:21 AM, Eric Wong <normalperson@yhbt.net> wrote:
> 
> > Right, we looked at using rename last year but I didn't think it's possible
> > given we need to write the pid file before binding new listen sockets
> >
> >   http://mid.gmane.org/20121127215146.GA23452@dcvr.yhbt.net
> >
> > But perhaps we can drop the pid file late iff ENV["UNICORN_FD"] is
> > detected.  I'll see if that can be done w/o breaking compatibility.
> 
> My opinion is that supporting backward compatibility cases that are
> clearly poorly designed, at least in open-source software, is
> ill-advised.  (I'm referring to the Mongrel compatibility semantics
> discussed in that article.)
> 
> That aside, I don't yet understand this "need" you're referring to.
> The control flow I'm proposing is as follows:

I'm not really sure, either; I just remember it was somewhat important
to Mongrel back then.  I'll get back to this later today/tomorrow.
Your control flow looks correct, though.

> > But NTP syncs early in the boot process before most processes (including
> > unicorn) are started.  It shouldn't matter, then, right?
> 
> Truth be told, I'm not completely certain why this is an issue.  My
> reading of procps and the kernel suggests it should be doing the right
> thing, but I tried this at first:
> 
> - Touch a timestamp file before sending P a SIGUSR2.
> - Wait for oldpid to disappear
> - Read the stime field from ps(1) for the remaining master process (P or P')
> - If stime < mtime of timestamp: new process failed.  If stime >
> mtime, new process succeeded.
> 
> But for reasons unclear to me, sometimes the stime of P' (successful
> reload) would predate the timestamp!  This was obviously agonizing.

OK, comparing mtime vs calculated value of stime is not possible because
of time adjustments.  Process start time is stored as monotonic time,
and calculated in ps(1) to real clock time.

So you can only compare stimes between different processes.  Comparing
stime to the mtime/ctime/atime of any file will not work reliably.
_______________________________________________
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