Fwd: [ginkgo] Fix for always selecting the proper pidfile location, even in the presence of a chroot. Fix for reload so that we properly pass an integer to os.kill. (d41f636)

[Jeff Lindsay]

Hey Alan, 

I don't quite follow this. Is this actionable to you?

-jeff

---------- Forwarded message ----------
From: Chad Selph <reply+c-1111491-9d97ee61c524b5...@reply.github.com>
Date: Tue, Mar 20, 2012 at 6:59 PM
Subject: Re: [ginkgo] Fix for always selecting the proper pidfile location, even in the presence of a chroot. Fix for reload so that we properly pass an integer to os.kill. (d41f636)
To: Jeff Lindsay <prog...@gmail.com>


I think this line is what is making services with stale pid files unable to start (#18), in python-daemon, there is a line that does:

```python
   if is_pidfile_stale(self.pidfile):
       self.pidfile.break_lock()
```

---
Reply to this email directly or view it on GitHub:
https://github.com/progrium/ginkgo/commit/d41f6364f38ffbbf6879d43a57ce53cd8e700c92#commitcomment-1111491

--
Jeff Lindsay
http://progrium.com

[Alan Shreve]

I figured out what the actual bug is last night. It's a bug in python-daemon. It checks whether the pidfile is stale _before_ it chroots, but it creates the pidfile _in_ the chroot. So it's checking the wrong location.

We can patch python-daemon and try to submit upstream, but I don't think python-daemon is maintained any longer (it hasn't seen a new version in almost 2 years). Maybe we should fork it? That or manage the chroot'ing ourselves to get around the bug.

- alan

[Jeff Lindsay]

I think we're going to have to drop python-daemon and do a lot of it ourselves. We have a fair amount of special needs since we've already been hacking around it. 

-jeff

[Alan Shreve]

We've only had to hack around two things so far which are: incomplete/incorrect support for chroots and the need for a hook after we daemonize but _before_ we chroot/drop privileges. And the need for that hook is a result of supporting gevent < 1.0. As I understand, gevent 1.0 should allow us to "reinit" the event loop after we daemonize and everything should still work.

- alan

[Jeff Lindsay]

Beyond that a lot of the structure of the runner is designed around python-daemon, not necessarily how it would ideally be designed. I'm just saying, I think it's worth doing it ourselves at this point.