I'd +1 Clint on this. I believe that the only right way to handle SIGHUP
for process running in foreground is to terminate.
--
Best regards,
Oleg Gelbukh
On Fri, Dec 20, 2013 at 10:54 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800:
So
On Fri, Dec 20, 2013 at 1:54 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800:
So a few people had been reporting recently that unstack no longer stops
nova processes, which I only got around to looking at today. It turns
out the new
On 12/20/2013 09:55 AM, Doug Hellmann wrote:
On Fri, Dec 20, 2013 at 1:54 AM, Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:
Excerpts from Sean Dague's message of 2013-12-19 16:33:12 -0800:
So a few people had been reporting recently that unstack no longer
On 12/20/2013 09:59 AM, Sean Dague wrote:
snip
So as Clint said, SIGHUP is only appropriate to do that *if* the process
is daemonized. If it's in the foreground it's not.
So that logic needs to be better.
This is basically a blocker for adding any upgrade testing from
something later than
On 12/20/2013 10:56 AM, Sean Dague wrote:
On 12/20/2013 09:59 AM, Sean Dague wrote:
snip
So as Clint said, SIGHUP is only appropriate to do that *if* the process
is daemonized. If it's in the foreground it's not.
So that logic needs to be better.
This is basically a blocker for adding any
On Fri, Dec 20, 2013 at 11:22 AM, Sean Dague s...@dague.net wrote:
On 12/20/2013 10:56 AM, Sean Dague wrote:
On 12/20/2013 09:59 AM, Sean Dague wrote:
snip
So as Clint said, SIGHUP is only appropriate to do that *if* the process
is daemonized. If it's in the foreground it's not.
So
Ok so this is interesting. I think this new feature will have caused
bugs in anything using this idiom:
def foo(bar=CONF):
because that is only evaluated at import time - any later reevaluation
of the config settings won't propagate into code. (This is why we
recently avoided that idiom in
