On 11.12.2013 15.54, Michael Fischer wrote:
On Tue, Dec 10, 2013 at 10:44 PM, Petteri Räty betelge...@gentoo.org wrote:
At least for pid based monitoring tools it is (I do agree with others
that you should also be monitoring http though). For example monit
requires that you give it a pid
On 26.11.2013 3.20, Eric Wong wrote:
I think the way 4.6.2 worked is better. There should be a pid file for
the new master process the moment it's created.
What do you think?
How about having the old process create a hard link to .oldbin,
and having the new one override the pid if
On 10.12.2013 21.52, Eric Wong wrote:
Petteri Räty betelge...@gentoo.org wrote:
On 26.11.2013 3.20, Eric Wong wrote:
How about having the old process create a hard link to .oldbin,
and having the new one override the pid if Process.ppid == pid file?
The check is still racy, but that's what
On 27.11.2012 4.02, Eric Wong wrote:
Petteri Räty betelge...@gentoo.org wrote:
On 27.11.2012 2.35, Eric Wong wrote:
nginx does not explicitly unlink the old pid file before it renames it
out of the way so yes matching nginx in that regard changes the behavior
exactly how I originally asked
On 26.11.2012 2.43, Eric Wong wrote:
Petteri Räty betelge...@gentoo.org wrote:
What follows are all the write actions related to unicorn pid file when
doing a hot restart. Seems like a bug to me that unicorn is deleting the
pid file before writing the new file. Is there a reason
On 26.11.2012 20.24, Eric Wong wrote:
The use case here is that with health monitors wouldn't have a window
where a pid file does not exist. With a hot restart it should always be
possible to have a pid file that points to either the old or the new master.
Then, doesn't nginx have the
On 27.11.2012 2.35, Eric Wong wrote:
nginx does not explicitly unlink the old pid file before it renames it
out of the way so yes matching nginx in that regard changes the behavior
exactly how I originally asked but you were against that. Maybe the
point is moot though.
Ah, I thought you
On 27.11.2012 2.35, Eric Wong wrote:
A small window is still a window.
Can't you make your health monitor check the state of the listening
ports as well? There's no point where a listening port will be
unavailable.
It's running on a PaaS but seems like a decent thing to suggest for
What follows are all the write actions related to unicorn pid file when
doing a hot restart. Seems like a bug to me that unicorn is deleting the
pid file before writing the new file. Is there a reason for it? It seems
to go against that rename that aims for an atomic replace that would
always
Hi,
unicorn unconditionally sets rack.multiprocess to true in the Rack
environment. The Rack spec [0] says the following about the variable:
true if an equivalent application object may be simultaneously invoked
by another process, false otherwise.
When unicorn is running with a single worker
On 18.10.2012 10.53, Eric Wong wrote:
Since a single process deployment is a corner-case in production
deployments, I don't think it's worth the effort to jump through hoops
and set rack.multiprocess=false automatically.
Do the workers currently know how many others there are? I am trying
11 matches
Mail list logo
