[sheepdog] [PATCH] logger: avoid using SIGHUP for detecting death of sheep

[Liu Yuan]

On Wed, Jan 15, 2014 at 04:49:23PM +0900, Hitoshi Mitake wrote:
> At Wed, 15 Jan 2014 11:13:50 +0800,
> Liu Yuan wrote:
> > 
> > On Tue, Jan 14, 2014 at 05:46:26PM +0900, Hitoshi Mitake wrote:
> > > It seems that current method of detecting sheep's death from logger
> > > process sometimes fails. The SIGHUP is caught as a request of log
> > > rotation.
> > > 
> > > The problem comes from that SIGHUP is used for both of log rotation
> > > request and death detection, and getppid() somestimes returns value
> > > not equal to 1 when SIGHUP which is caused by the death rises.
> > 
> > why not == 1 if sheep dies? I think we need to find the root cause instead of
> > a workaround.
> 
> I don't know why. It would be a timing problem. So I employed a
> certainly usable way.
> 
> BTW, how to detect death of sheep is clearly a trivial problem and
> finding the root cause is time consuming. As you saied in other mail,
> current code of sheepdog has many existing problems. Do we really need
> to discuss on this topic?

It might be a trivial but this is a question any reviewer might ask. This is not a
stone I throw at you, instead, I just wanted to find out better solution(if possible)
and understand the situation better.

> My company doesn't have enough resource. e.g. our internal team has
> bunch of issues on our internal trackers. In addition, unfortunately,
> we don't have time and human resource for migrating the issues to our
> public launchpad tracker. We are working on development of a product
> in a very tight schedule. The final deadline is set in this March. And
> we have an intermediate period of development this month. The
> situation is really worse.
> Our community doesn't have enough developers, too. Discussion on a
> trivial topic and consuming our time is harmful for development
> speed. Some external users already deployed sheepdog on their
> production environment, too. e.g. look at this site:
> http://rentalprivatecloud.jp/feature/index.html (there is no English
> page but you can find a string "sheepdog" in this page easily).
> So improving quality is a serious urgent requirement. If some of the
> services or products don't work well, it is harmful for trust of
> sheepdog.
> 
> Of course I sometimes introduce bugs. The recent vnode info leak would
> be the worst one. I really apologize for that. But I sometimes also
> remove bugs introduced by your commit. I guess that means we are even.

I have no idea what you talked about. I think you took me wrong sometimes, I
never (at least try my best) try to comment on people, instead I comment only on
patch(s). Whoever submit the patch, I'll raise a question about the patch if
I have in mind. Don't take it peronsally and my comment will never say the
quality of a person. It is all about the patch itself.

> 
> Let's stop time consuming discussion on trivial topics like how to
> detect death of sheep, coding policy of test script, etc .

I never disrespect the coding style of others. I assume you meant the patch
that enable '-z x' option passing and I think we already reached a agreement
that the final version is better than previous one. Isn't this the value of
discussion of a patch? Whoever wrote the first version would be rejected because
there was pending comments not resolved.

> I think we
> need to cooperate for smooth and rapid development. At least I want to
> cooperate with you.

Compared with most of opensource community, our patch submission and merging is
really fast (due to lack of developer review). Most of patch will be merged in
one day and reviewd on daily basis. If you take a look at Linux or QEMU, openstack
review process, you'll find most of patches will last weeks, even months, years
to get accepted and version iteration of patch will be averagely larger than
ours.

It's my duty to review every patch and comment on it to get a better one. Again,
I think you take it wrong that I just go aginst your patches.

Thanks
Yuan