API doesn't quit when api.workers > 0

[Steve McLellan]

When the API is configured to have more than 0 workers (the default), it fails to exit cleanly with Ctrl+C:

In config:

   [api]
   workers = 0

After running the API:

    searchlight-api --config-file etc/searchlight.conf
    ....
    2016-01-26 17:14:52.209 4696 INFO searchlight.common.wsgi [-] Starting 1 workers
    2016-01-26 17:14:52.210 4696 INFO searchlight.common.wsgi [-] Started child 4698
    2016-01-26 17:14:52.212 4698 INFO eventlet.wsgi.server [-] (4698) wsgi starting up on http://0.0.0.0:9393

Ctrl+C, then log continues:

    2016-01-26 17:15:38.962 4696 INFO searchlight.common.wsgi [-] Removed dead child 4698
    2016-01-26 17:15:38.965 4696 INFO searchlight.common.wsgi [-] Started child 4699
    2016-01-26 17:15:38.966 4699 INFO eventlet.wsgi.server [-] (4699) wsgi starting up on http://0.0.0.0:9393

It looks like there's a problem with detecting exit codes, but I've not dug into it more yet.

[Liyingjun (liyingjun)]

I can't reproduce this bug

/usr/local/bin/searchlight-api --config-file /etc/searchlight/searchlight.conf
Option "verbose" from group "DEFAULT" is deprecated for removal. Its value may be silently ignored in the future.
2015-12-11 17:09:31.257 WARNING oslo_log.versionutils [-] Deprecated: WritableLogger() is deprecated as of Liberty and may be removed in Mitaka. It will not be superseded.
2015-12-11 17:09:31.424 WARNING oslo_config.cfg [-] Option "policy_file" from group "DEFAULT" is deprecated. Use option "policy_file" from group "oslo_policy".
2015-12-11 17:09:31.430 WARNING oslo_config.cfg [-] Option "username" from group "keystone_authtoken" is deprecated. Use option "user-name" from group "keystone_authtoken".
2015-12-11 17:09:31.431 WARNING keystonemiddleware.auth_token [-] signing_dir mode is 0755 instead of 0700
2015-12-11 17:09:31.438 INFO searchlight.common.wsgi [-] Starting 3 workers
2015-12-11 17:09:31.441 INFO searchlight.common.wsgi [-] Started child 106449
2015-12-11 17:09:31.442 INFO eventlet.wsgi.server [-] (106449) wsgi starting up on http://0.0.0.0:9393/
2015-12-11 17:09:31.445 INFO searchlight.common.wsgi [-] Started child 106450
2015-12-11 17:09:31.446 INFO eventlet.wsgi.server [-] (106450) wsgi starting up on http://0.0.0.0:9393/
2015-12-11 17:09:31.450 INFO searchlight.common.wsgi [-] Started child 106451
2015-12-11 17:09:31.451 INFO eventlet.wsgi.server [-] (106451) wsgi starting up on http://0.0.0.0:9393/
^C2015-12-11 17:09:33.750 INFO searchlight.common.wsgi [-] Removed dead child 106449
2015-12-11 17:09:33.754 INFO searchlight.common.wsgi [-] Started child 106458
2015-12-11 17:09:33.755 INFO eventlet.wsgi.server [-] (106458) wsgi starting up on http://0.0.0.0:9393/
2015-12-11 17:09:33.757 INFO eventlet.wsgi.server [-] (106458) wsgi exited, is_accepting=True
2015-12-11 17:09:33.758 INFO searchlight.common.wsgi [-] Child 106458 exiting normally

[Steve McLellan (sjmc7)]

Li - your log output still looks unusual (though different). Notice after the ctrl+c you get 'removed dead worker', then immediately 'started child'., which was then told to exit. It looks in your case like it did exit correctly. I'm running on OS X and Travis has also seen this, so it may be an incompatibility there. I'll try and test on linux later.

[Steve McLellan (sjmc7)]

This does seem to be a problem specific to OS X. I get the same output as Li in Linux (the final 'starting up' and 'exited' still look weird, but it does exit properly).

[Steve McLellan (sjmc7)]

Downgrading since it's an OS X issue only.

[Travis Tripp (travis-tripp)]

Can this other fix be applied to this issue as well: https://review.openstack.org/#/c/283950/

[Hari (hosingh000)]

Commit is already proposed by Travis, Can we close this defcet