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

[Hitoshi Mitake]

At Wed, 15 Jan 2014 16:21:00 +0800,
Liu Yuan wrote:
> 
> 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.

"-z x" is just an example. I wanted to say that we tend to consume
time for disucssing on trivial topics in these days. sheepdog is very
younger than linux, qemu and openstack and we have bunch of todos. And
many of them are related to essential design of sheepdog. We should
consume time on the essential design.

Thanks,
Hitoshi