yahoo-eng-team team mailing list archive

[Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>]

** Description changed:

- In order to more effectively manage the unlinked and open (lsof +L1) log
- files descriptors w/o restarting the services, SIGHUP signal should be
- accepted by every Openstack service.
+ 1)In order to more effectively manage the unlinked and open (lsof +L1)
+ log files descriptors w/o restarting the services, SIGHUP signal should
+ be accepted by every Openstack service.
  
  That would allow, e.g. logrotate jobs to gracefully HUP services after
  their log files were rotated. The only option we have for now is to
  force the services restart, quite a poor option from the services
  continuous accessibility PoV.
  
  Note: according to  http://en.wikipedia.org/wiki/Unix_signal
  SIGHUP
-    ... Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.
+    ... Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.
+ 
+ Currently Murano and Glance are out of sync with Oslo SIGHUP support.
+ 
+ There is also the following issue exists for some of the services of OS projects with synced SIGHUP support:
+ 2)
+ heat-api-cfn, heat-api, heat-api-cloudwatch, keystone:  looks like the synced code is never being executed, thus SIGHUP is not supported for them. Here is a simple test scenario:
+ 2.1) modify <python-path>/site-packages/<foo-service-name>/openstack/common/service.py
+ def _sighup_supported():
+ +    LOG.warning("SIGHUP is supported: {0}".format(hasattr(signal, 'SIGHUP')))
+     return hasattr(signal, 'SIGHUP')
+ 2.2) restart service foo-service-name and check logs for "SIGHUP is supported", if service  really supports it, the appropriate messages would be present in the logs.
+ 2.3) issue kill -HUP <foo-service-pid> and check logs for "SIGHUP is supported", if service  really supports it, the appropriate messages would be present in the logs. Besides that, the service should remain started and its main thread PID should not be changed.
+ 
+ 3)
+ nova-cert, nova-novncproxy, nova-objectstore, nova-consoleauth, nova-scheduler - in case of the kill -HUP <foo-service-pid> command was issued, the associated service would have got dead, but there are SIGHUP related messages in the logs. But the service should remain started and its main thread PID should not be changed.
+ 
+ So, looks like there is a lot of things still should be done to ensure
+ POSIX standards abidance in Openstack :-)

** Also affects: nova
   Importance: Undecided
       Status: New

** Also affects: heat
   Importance: Undecided
       Status: New

** Also affects: keystone
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1276694

Title:
  Openstack services should support SIGHUP signal

Status in OpenStack Image Registry and Delivery Service (Glance):
  Confirmed
Status in Orchestration API (Heat):
  New
Status in OpenStack Identity (Keystone):
  New
Status in Murano:
  Confirmed
Status in OpenStack Compute (Nova):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Invalid

Bug description:
  1)In order to more effectively manage the unlinked and open (lsof +L1)
  log files descriptors w/o restarting the services, SIGHUP signal
  should be accepted by every Openstack service.

  That would allow, e.g. logrotate jobs to gracefully HUP services after
  their log files were rotated. The only option we have for now is to
  force the services restart, quite a poor option from the services
  continuous accessibility PoV.

  Note: according to  http://en.wikipedia.org/wiki/Unix_signal
  SIGHUP
     ... Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.

  Currently Murano and Glance are out of sync with Oslo SIGHUP support.

  There is also the following issue exists for some of the services of OS projects with synced SIGHUP support:
  2)
  heat-api-cfn, heat-api, heat-api-cloudwatch, keystone:  looks like the synced code is never being executed, thus SIGHUP is not supported for them. Here is a simple test scenario:
  2.1) modify <python-path>/site-packages/<foo-service-name>/openstack/common/service.py
  def _sighup_supported():
  +    LOG.warning("SIGHUP is supported: {0}".format(hasattr(signal, 'SIGHUP')))
      return hasattr(signal, 'SIGHUP')
  2.2) restart service foo-service-name and check logs for "SIGHUP is supported", if service  really supports it, the appropriate messages would be present in the logs.
  2.3) issue kill -HUP <foo-service-pid> and check logs for "SIGHUP is supported", if service  really supports it, the appropriate messages would be present in the logs. Besides that, the service should remain started and its main thread PID should not be changed.

  3)
  nova-cert, nova-novncproxy, nova-objectstore, nova-consoleauth, nova-scheduler - in case of the kill -HUP <foo-service-pid> command was issued, the associated service would have got dead, but there are SIGHUP related messages in the logs. But the service should remain started and its main thread PID should not be changed.

  So, looks like there is a lot of things still should be done to ensure
  POSIX standards abidance in Openstack :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1276694/+subscriptions