Open Stack

On 12/20/2013 09:55 AM, Doug Hellmann wrote:
> 
> 
> 
> On Fri, Dec 20, 2013 at 1:54 AM, Clint Byrum <clint at fewbar.com
> <mailto:clint at 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 common.service stack from oslo takes SIGHUP and treats
>     it as
>     > a restart. Which isn't wrong, but is new, and is incompatible with
>     > screen (the way we use it). Because we use -X stuff, the resulting -X
>     > quit sends SIGHUP to the child processes.
>     >
>     > So the question is, are we definitely in a state now where nova
>     services
>     > can and do want to support SIGHUP as restart?
>     >
>     > If so, is there interest in being able to disable that behavior at
>     start
>     > time, so we can continue with a screen based approach as well?
>     >
>     > If not, we'll need to figure out another way to approach the
>     shutdown in
>     > devstack. Which is fine, just work that wasn't expected.
>     >
> 
>     Perhaps if the process is running in the foreground, as it does in
>     devstack, it should still terminate on SIGHUP rather than restart.
> 
> 
> It looks like the changes to ServiceLauncher.wait() that introduced this
> behavior are related to
> https://blueprints.launchpad.net/oslo/+spec/cfg-reload-config-files
> where we wanted a service to be able to re-read its configuration files
> on a signal. HUP seems appropriate for a production
> environment, but probably not for development.
> 
> I opened https://bugs.launchpad.net/oslo/+bug/1263122 to track the fix.

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.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131220/7b3ea0c6/attachment.pgp>